La réalité du développement logiciel

Prenez un développeur. Tenez, par exemple, le fils de la voisine, vous savez, celui qui est un peu pâle à force de passer la journée dans sa chambre, à jouer ou à coder. Il a bien un peu de temps libre pour vous.

Parlez-lui de votre idée, montrez-lui 2 ou 3 exemples d'application dont le visuel vous plaît, dites-lui bien de faire simple. Attendez quelques jours et hop ! Le logiciel de vos rêves est là. Et pour pas cher !

Non ?

1functioncreateSoftware() {
2// It's not that simple...
3}

La réalité est plus complexe

D'accord, c'est une caricature. Mais... Face à l'abondance de promesses pour "programmer sans formation et sans coder" (l'IA en étant le dernier avatar), difficile de comprendre ce qui se cache derrière un logiciel.

Code10%
Pas code90%

Ce qui est évident : un logiciel, c'est du code. Beaucoup de code. Produit par des développeurs. Et oui, certains ont débuté leur apprentissage depuis leur chambre — nous les premiers.

Ce code est en partie généré et contrôlé par des outils plus ou moins évolués ("IA"), sous la supervision des développeurs. Mais le code, c'est à peine 10% du travail nécessaire.

Le site vitrine très simple, les formules Excel du collègue débrouillard, l'application sur mesure créée par un conjoint enthousiaste... peuvent fonctionner correctement.
L'ennemi, c'est la complexité. A partir d'un certain seuil, tout projet finit par rencontrer un mur. Les délais ne sont plus tenus, les bugs s'empilent, le budget explose.

Ce que nous savons faire : anticiper, repousser, contourner, franchir le mur de la complexité.
Méthode et expérience : cet obstacle, nous l'avons rencontré des dizaines de fois sur nos projets étudiants, personnels et plus tard professionnels.

Comment échouer ?

Il suffit de s'occuper uniquement du code et de délaisser les 90% restants.

Ne pas poser le besoin

Il est tellement évident... et pourtant personne n'est d'accord sur ce que le logiciel doit faire. Dans le doute, le développeur fait "au mieux" : un choix arbitraire ou aléatoire.

Ne pas clarifier le vocabulaire

Surtout celui qui semble trivial. C'est quoi un "utilisateur", une "personnalisation", une "notification" ?

Tout développer d'un coup

Idéal pour pour rendre le projet indigeste, se perdre et laisser le planning dériver... La bonne pratique : des chantiers à taille humaine, modestes, rapides, maîtrisés.

Oublier que le logiciel est vivant

Un logiciel n'est jamais vraiment terminé. Vous aurez toujours des idées pour l'enrichir, satisfaire un besoin utilisateur, améliorer une fonctionnalité...

Croire que le logiciel tourne tout seul

Le laisser dans un coin, c'est la meilleure façon de ne jamais anticiper les pannes en production...

Négliger la qualité

Peu importent le contrat, le budget ou les délais : un logiciel bourré de bugs, c'est le meilleur moyen de fâcher tout le monde.

Notre approche

Nous gérons la complexité avec méthode et expérience.

Le paquebot et le pilote

Un logiciel, dès qu'il grossit, ressemble vite à un paquebot avec beaucoup d'inertie. Notre rôle, c'est de vous signaler les points de friction le plus tôt possible, pour minimiser leurs impacts.

L'expérience qui compte

Nous n'avons pas de recette magique, seulement l'expérience de dizaines de projets... et de tout ce qui peut bloquer le votre.

Le projet réussi

Le projet réussi ? C'est quand vous nous trouvez bien prudents. Tout s'est bien déroulé, non ? On n'aurait pas pu juste coder ?

Parce que moi, j'ai une voisine dont le fils s'y connaît un peu, alors, peut-être que pour la prochaine fois...