Barbecue IA : pourquoi les projets informatiques dérapent-ils si souvent ?
Premier épisode de Barbecue IA : pourquoi les projets informatiques dépassent souvent les budgets, les délais et les attentes.
Les idées passent au grill
Épisode 1 : Pourquoi les projets informatiques dérapent-ils si souvent ?
« Ici, on ne juge pas les personnes. On met les idées au grill. Et parfois... elles en ressortent meilleures. »
J'ai parcouru des centaines d'articles sur la gestion de projet. Tous parlent d'agilité, de méthodes, de communication ou d'organisation. Pourtant, les projets continuent de dépasser les budgets, les délais et les attentes.
Alors je vais te poser une question très simple.
Pourquoi les projets informatiques dérapent-ils ?
Je vais peut-être te surprendre, mais je n'ai presque jamais rencontré un projet qui démarrait sur un faux besoin.
Quand une entreprise investit dans un logiciel, ce n'est pas pour le plaisir. Il y a toujours un problème réel à résoudre.
Le besoin existe.
Le problème arrive après.
Donc ce ne serait pas le besoin qui est mauvais... mais ce qu'on en fait ?
Exactement.
Au départ, on répond à un besoin précis.
Puis quelqu'un dit :
"Puisqu'on y est, on pourrait aussi..."
Et cette phrase est redoutable.
Une idée en appelle une autre.
Puis une troisième.
Puis une quatrième.
Aucune n'est absurde. Au contraire. Elles sont souvent pertinentes.
Mais leur accumulation finit par transformer un projet simple en projet complexe.
Attends...
Tu es en train de m'expliquer qu'un projet échoue... parce que les équipes veulent bien faire leur travail ?
C'est paradoxal.
Ce n'est pas le fait de vouloir bien faire qui pose problème.
C'est de vouloir tout faire.
Tout de suite.
On confond souvent qualité et exhaustivité.
On croit qu'un bon logiciel est un logiciel qui a pensé à tout.
Je pense exactement l'inverse.
Un bon logiciel est un logiciel qui répond parfaitement à un besoin précis.
Le reste peut venir après.
Pourtant, les utilisateurs demandent toujours davantage.
Une nouvelle fonctionnalité.
Une amélioration.
Un raccourci.
Tu leur dis non ?
Pas assez souvent.
Et je pense que beaucoup de développeurs sont comme moi.
On aime rendre service.
On veut que le client soit satisfait.
On veut qu'il dise :
"Ils ont même pensé à ça !"
Le problème, c'est que chaque petit "plus" paraît anodin.
Mais à la fin, ils forment une montagne.
Donc le vrai problème, ce n'est peut-être pas le client.
C'est notre incapacité à dire :
"Pas maintenant."
Oui.
Parce qu'il existe une autre erreur.
On imagine souvent qu'un cahier des charges peut être complet.
Je n'y crois pas.
Après plus de vingt-cinq ans de développement, je n'en ai jamais vu un seul qui anticipe tout.
Et c'est normal.
On ne peut pas prévoir les exceptions.
Encore moins les exceptions... des exceptions.
Le vrai usage d'un logiciel n'apparaît qu'au moment où quelqu'un commence réellement à l'utiliser.
Donc finalement...
Tu ne cherches plus à construire un projet parfait.
Tu cherches à construire un projet qui accepte d'être incomplet.
Exactement.
Pour moi, la bonne approche est presque contre-intuitive.
On réalise d'abord le périmètre prévu.
Rien de plus.
On valide que le besoin initial est réellement couvert.
On observe.
On teste.
On écoute.
Et seulement ensuite...
on améliore.
Le logiciel grandit avec son utilisateur.
Pas dans l'imagination de son concepteur.
Je crois que je viens de comprendre quelque chose.
Pendant toute cette discussion, je pensais que tu allais me parler de méthodes agiles, de Scrum ou d'architecture logicielle.
En réalité...
tu m'as surtout parlé d'humilité.
Accepter qu'on ne sait pas tout.
Accepter qu'un projet découvre sa forme en avançant.
Et surtout...
résister à la tentation de vouloir construire la version parfaite avant même d'avoir validé la première.
Ce qui a survécu au grill
Un projet informatique ne dérape pas parce qu'il y a trop d'idées.
Il dérape parce qu'on veut toutes les réaliser avant d'avoir validé la première.
À la semaine prochaine.
Une nouvelle idée passera au grill.