Pourquoi la Plupart des Projets Logiciels Échouent Avant la Première Ligne de Code

La plupart des post-mortems d’un projet logiciel raté pointent vers les trois mêmes mots : « le périmètre n’a cessé de changer ». Mais le périmètre ne change pas tout seul. Il change parce que personne n’a mis le cahier des charges à l’épreuve avant qu’un seul écran ne soit conçu ou qu’une seule ligne de code ne soit écrite.

Le schéma derrière chaque estimation ratée

Nous avons hérité d’assez de plateformes inachevées pour voir le schéma clairement. Un client décrit ce qu’il veut en un paragraphe. Une équipe estime ce paragraphe. Le développement commence. Trois semaines plus tard, quelqu’un demande « attendez, que se passe-t-il quand un utilisateur fait X ? » — et X n’a jamais été discuté, parce que X n’était pas dans le paragraphe.

Ce n’est pas un problème technologique. C’est un problème de découverte, et il se résout avant que quiconque ne touche un clavier.

À quoi ressemble vraiment la phase de découverte

Chez TECHALION, chaque projet démarre par une phase de découverte conçue spécifiquement pour faire émerger les questions qu’un cahier des charges d’un paragraphe dissimule : qui utilise réellement ce système au quotidien, ce qui pose problème si le projet prend du retard, quelles données existent déjà par rapport à ce qui doit être construit, et quelle exigence « évidente » sera en réalité la plus difficile à réaliser. Ce n’est pas une formalité — c’est le moment où le coût réel d’un projet est évalué honnêtement, avant d’être verrouillé dans un contrat.

Le résultat n’est pas un moodboard. C’est un plan cadré que vous pourriez confier à n’importe quelle équipe compétente en attendant le même résultat — parce que les décisions difficiles ont déjà été prises, sur papier, quand il était encore facile et peu coûteux de les changer.