Faire vite coûte souvent plus cher que faire bien.
Introduction : Le syndrome du « ça passe »
Aujourd’hui, dans les projets IT, on ne code plus, on bricole.
On ne teste plus, on croise les doigts.
Et on ne documente plus, on espère que Jean-Michel sera encore là dans six mois.
Pourquoi cette fuite en avant ? Pourquoi est-ce devenu normal de livrer un projet bancal, à moitié testé, difficilement maintenable, et souvent incompris de ceux qui vont devoir le maintenir ?
1. Le budget et le délai, nouveaux leaders du projet
Ce n’est plus un projet, c’est une course contre la montre avec un caillou dans la chaussure sur un chemin couvert d’oeufs.
- La date de mise en production est décidée avant même de connaître la charge.
- Le client veut du « rapide et pas cher », comme s’il commandait une pizza.
- Le budget est validé sur la base d’hypothèses optimistes, présentées dans un PowerPoint d’avant-vente aussi convaincant qu’une pub de lessive.
- L’architecte d’entreprise insère trois boîtes dans un diagramme, coche sa case TOGAF, et passe au suivant.
- L’architecte solution a une semaine pour proposer une architecture cohérente, sans spécifications, ni contexte métier solide.
- L’équipe, elle, bricole en apnée pour livrer dans le planning, en espérant que ça tiendra jusqu’à la prochaine réunion de crise (qui durera deux heures et ne résoudra rien).
Il y a longtemps, une rumeur courrait sur mon projet, Nous sommes fin décembre/ début janvier. Deux Directeurs s’étaient mis d’accord sur un terrain de golf, l’un avait juste demandé à l’autre si son entreprise pouvait lui livrer un projet avant la fin de l’année. Et il a dit oui. De là, un business plan est créé, des spécifications générales sont écrites, un appel d’offre est lancé. La date de mise en productione est décidé, ce sera fin septembre. En moins de 9 mois, les SNE doivent répondre à l’appel d’offre, mettre en place une infrastructure, coder le projet, le tester et le livrer. Cela serait possible pour un petit projet. Mais là, ce n’était pas le cas. Les équipes ont trimé, le projet fut livré dans les temps. Ce ne fut pas une catastrophe, heureusement, mais ce ne fut pas un grand succès commercial non plus.
2. Le mythe du MVP (Minimum Viable Plantage)
On nous vend du MVP, mais en réalité, c’est souvent du Minimum Viable Problème.
Le strict minimum pour que ça ne plante pas immédiatement.
Le MVP est devenu le Minimum Viable pour la Prod : on fait le minimum, et ensuite, on prie.
Sauf que tout ce qui n’est pas pensé dès le début devient exponentiellement plus coûteux à corriger :
- Maintenabilité ? « On verra plus tard. »
- Tests ? « Pas le temps, on fera ça en prod. »
- Sécurité ? « On mettra un captcha. »
- Et la documentation ? « Y’a les commits Git, non ? »
Et puis… plus tard, c’est trop tard. Le projet a muté, il est marqué « Trouble » et la réputation du projet est faite, cela devient presque une punition de travailler dessus.
3. Les détails ? Des « nice to have »… sauf quand tout s’effondre
Le diable est dans les détails, mais le budget ne couvre pas les détails.
Et dans un système informatique, les détails que l’on met de côté sont toujours ceux qui explosent en premier :
- Un oubli de validation,
- Une mauvaise gestion des erreurs,
- Une dépendance non verrouillée,
- Une config test restée en prod…
Bref, tout ce qu’on appelle ensuite une « anomalie bloquante ».
4. Où sont passées les équipes de tests ?
Avant, on avait des testeurs, des QA, des gens payés pour douter de tout, même du bouton « OK ». Des gens qui cliquaient comme des maniaques 15 fois sur le bouton « Confirmer »… et qui voyaient 15 lignes arriver dans la base de données.
Aujourd’hui ? Ils ont disparu. Comme les spécifications fonctionnelles. Comme la conception technique.
« Non mais les devs vont tester leurs propres devs, non ? »
On colle du Sonar, on affiche un 80% de couverture, et on coche la case « c’est bon ».
Mais :
- Les tests d’intégration ?
- Les End-to-End ?
- La recette fonctionnelle ?
- Les tests de charge, de non-régression ?
Disparus. Comme les budgets pour les faire.
5. Faire bien, c’est devenu subversif
Proposer de faire bien, aujourd’hui, c’est limite un acte de rébellion. En fait, tout le monde est d’accord, mais tout le monde sait que le budget ne le permet pas.
- On te regarde comme si tu proposais de réécrire SAP en COBOL.
- On te dit « non mais on fera ça plus tard », dans un sprint magique qu’on appellera « tech debt ».
- Et bien sûr : « Là, on est en agilité », comme si « agilité » voulait dire « zéro réflexion, zéro relecture, zéro QA ».
Tu passes pour le vieux qui « bloque le projet », alors que tu sais juste ce que ça coûte de faire n’importe quoi, et ça coûte cher. Cela s’appelle l’expérience, pas la nostalgie.
Conclusion :
Si on n’a pas le temps de faire les choses bien, aurons-nous le temps de réparer les choses mal faites ?
Un projet mal conçu ne se bonifie pas avec le temps. Il pourrit, il se complique… et il explose à la figure dde celui qui est juste venu changer un bouton.
