Le code se corrige. La confiance se reconstruit. Mais une occasion perdue ne se représente pas toujours.
Après plus de 30 ans en informatique, j’ai appris qu’un projet peut échouer même lorsque les problèmes techniques sont parfaitement corrigibles. Nous accordons beaucoup d’importance à la qualité du code, aux technologies et aux délais. Pourtant, un élément peut compromettre tout ce travail : l’écart entre les attentes du client et ce que l’équipe croit devoir livrer.
Cet écart peut sembler mineur sur le plan technique, mais ses conséquences humaines et commerciales peuvent être considérables.
Une occasion d’affaires prometteuse
Imaginons une équipe de développement invitée à réaliser une démonstration pour une entreprise qui souhaite sélectionner un nouveau fournisseur. Le mandat pourrait déboucher sur un contrat important et une collaboration à long terme.
Le client fournit une description relativement claire de l’application attendue. Les fonctionnalités principales sont identifiées et l’équipe dispose des compétences nécessaires. Le développement progresse rapidement, notamment grâce aux outils d’intelligence artificielle, et une application fonctionnelle est prête pour la présentation.
Mais le jour de la démonstration, la rencontre prend une tournure inattendue.
Le client pose des questions sur des comportements qui n’avaient pas été décrits. Il cherche des fonctionnalités absentes des exigences initiales et semble s’attendre à des résultats différents. L’équipe explique ses choix et précise que plusieurs de ces éléments pourraient être ajoutés lors d’une prochaine itération.
Techniquement, rien ne semble insurmontable. Pourtant, l’enthousiasme initial disparaît et la discussion porte désormais davantage sur ce qui manque que sur ce qui a été accompli. Ce qui devait être une occasion de démontrer l’expertise de l’équipe devient une tentative de justifier les limites de l’application.
Quand la déception coûte plus cher que les corrections
Quelques jours plus tard, l’entreprise annonce qu’elle ne retiendra pas cette équipe comme fournisseur. Le contrat est perdu, malgré une application fonctionnelle et des problèmes qui auraient probablement pu être corrigés rapidement.
C’est l’un des aspects les plus difficiles de ce genre de situation : avoir le sentiment d’avoir raté une occasion alors que les moyens de réussir étaient à notre portée. La démonstration n’a pas nécessairement échoué sur le plan technique, mais elle n’a pas convaincu.
Il serait facile d’accuser le client d’avoir mal défini ses besoins. Pourtant, certaines attentes peuvent lui sembler tellement évidentes qu’il ne pense pas à les formuler. De son côté, une équipe peut respecter les exigences écrites sans comprendre toutes les attentes qui les accompagnent.
Personne n’a nécessairement commis de faute grave, mais le résultat demeure le même : une occasion importante a été perdue.
Les exigences ne racontent pas toujours toute l’histoire
Un cahier des charges peut être clair sans décrire toutes les attentes du client. Il faut distinguer les exigences exprimées, les besoins réels de l’entreprise et les critères qui permettront de considérer le résultat comme une réussite.
Ces éléments devraient converger, mais ce n’est pas toujours le cas. Une application peut respecter les exigences communiquées sans correspondre entièrement à la façon dont le client imaginait son fonctionnement.
Je crois qu’une bonne analyse des besoins constitue l’un des meilleurs investissements dans un projet informatique. Si l’intelligence artificielle nous permet de produire du code plus rapidement, pourquoi ne pas consacrer davantage de temps à comprendre ce que nous devons construire?
Cela ne signifie pas rédiger un cahier des charges de centaines de pages. Il faut plutôt documenter les objectifs, les processus métier, les contraintes, les priorités et les critères de validation.
Dans le cas d’une démonstration, une question supplémentaire devient essentielle : sur quels critères le client évaluera-t-il le résultat? Une preuve de concept, un prototype et une application presque complète ne répondent pas aux mêmes attentes.
La communication et l’approche Agile
Une bonne collaboration commence avant la première ligne de code. Le client doit expliquer son contexte et ses objectifs, mais il appartient aussi au fournisseur de poser les bonnes questions, de relever les ambiguïtés et de confirmer sa compréhension.
J’aborde d’ailleurs ce sujet dans ma ressource Bien formuler une demande de services en développement Internet, qui présente les renseignements utiles pour préparer une demande de propositions ou un cahier des charges.
Une méthodologie Agile permet ensuite de maintenir cette collaboration tout au long du développement. En impliquant régulièrement le client, les développeurs, les analystes et les utilisateurs concernés, l’équipe peut valider ses hypothèses, présenter progressivement les fonctionnalités et corriger les incompréhensions avant qu’elles deviennent coûteuses.
L’approche Agile ne dispense pas de documenter les exigences. Elle permet plutôt de maintenir une documentation utile et évolutive, accompagnée d’échanges réguliers. Dans le cas d’une démonstration ponctuelle, où plusieurs itérations ne sont pas toujours possibles, la validation préalable des attentes devient encore plus importante.
L’intelligence artificielle au service de la compréhension
On parle beaucoup de l’IA comme d’un outil permettant d’accélérer la programmation. Pourtant, elle peut également contribuer à structurer un cahier des charges, repérer des ambiguïtés, proposer des scénarios d’utilisation et préparer des critères d’acceptation.
Elle ne remplacera jamais les échanges avec le client et ne pourra pas deviner avec certitude toutes les attentes non exprimées. Mais elle peut nous aider à poser de meilleures questions avant de commencer le développement.
Avec l’expérience, je suis devenu particulièrement sensible à la différence entre une réalisation techniquement réussie et un projet véritablement réussi. La seconde exige non seulement des compétences techniques, mais aussi de l’écoute, de l’analyse et une compréhension des attentes humaines.
Les outils changent et les méthodes évoluent, mais notre responsabilité demeure : nous assurer que nous construisons la bonne solution, pour les bonnes raisons, avec les bonnes personnes.
Car le code se corrige et la confiance se reconstruit. Mais une occasion perdue ne se représente pas toujours.