La plupart des projets technologiques échouent avant même de commencer.
Pas à cause de la technologie.
Pas à cause du budget.
Mais à cause d’une chose beaucoup plus simple :
On ne sait pas vraiment quel problème on essaie de résoudre.
On aime croire que les projets technologiques commencent quand on développe quelque chose.
Un dashboard.
Une application.
Un modèle d’intelligence artificielle.
En réalité, ils commencent bien avant.
Ils commencent au moment où quelqu’un dit : « On a besoin de… »
Et c’est précisément là que tout se joue.
Le vrai problème des projets de transformation numérique
Chaque année, les organisations investissent massivement en technologie.
Pourtant, une grande partie de ces initiatives ne livrent pas la valeur attendue.
Selon Gartner, dans son article « Why Enterprises Fail to Realize Business Outcomes From Technology » (2025), le principal obstacle à la réussite des investissements technologiques n’est pas technique.
C’est le fait de ne pas être capable de mesurer leur impact sur les résultats d’affaires, une réalité qui touche près de 39 % des organisations.
Autrement dit, dans près d’un cas sur deux, on ne sait même pas si l’investissement valait la peine.
Le problème n’est même pas de livrer.
C’est de savoir si ce qu’on a livré a changé quelque chose.
On livre des solutions.
Mais on ne sait pas si elles créent de la valeur.
Ce qu’on confond trop souvent
Dans beaucoup d’organisations, un projet commence comme ça :
« On veut un dashboard. »
« On veut mieux suivre la performance. »
« On veut faire de l’IA. »
Ce ne sont pas des besoins.
Ce sont :
- Des intentions
- Des raccourcis
- Ou pire : des solutions déjà choisies
Et c’est là que le problème commence.
Un mauvais besoin bien exécuté reste un mauvais projet
On parle souvent des risques d’un projet :
- Dépassement de budget
- Délais
- Qualité du livrable
Mais le plus grand risque est rarement celui-là.
Le plus grand risque, c’est de résoudre le mauvais problème.
On optimise l’exécution.
On accélère la livraison.
Mais si le besoin est mal défini, on ne fait qu’accélérer dans la mauvaise direction.
Un projet technologique ne crée pas de valeur.
Il amplifie les décisions qui ont été prises avant.
La prise de besoin, c’est déjà une décision
Une solution technologique ne fait pas qu’exécuter.
Elle fige des choix :
- Quels indicateurs comptent
- Comment ils sont calculés
- Quelles données sont considérées comme « justes »
- Quelles décisions sont facilitées… ou impossibles
Autrement dit, la prise de besoin est déjà une décision d’architecture.
Pas technique.
Mais décisionnelle.
Le problème : on traite encore ça comme une formalité
Dans trop de projets, la prise de besoin ressemble à ça :
- Une rencontre rapide
- Une liste de demandes
- Une traduction en requis
On documente.
On reformule.
Mais on ne challenge pas vraiment.
Résultat :
On construit exactement ce qui a été demandé… sans valider si c’était la bonne chose à demander.
Ce que les experts confirment (et que tout le monde observe sur le terrain)
Trois constats reviennent systématiquement et sont notamment documentés par Gartner dans son article « What CIOs Must Get Right to Drive Digital Transformation Value » (2026) :
Les projets ne sont pas assez ancrés dans des résultats d’affaires
→ On parle d’outils, pas d’impact
Les initiatives ne sont pas alignées sur des priorités claires
→ Trop de projets, pas assez de valeur
Les résultats ne sont pas mesurés correctement
→ Donc ils ne sont pas défendables
Résultat : l’organisation crée du mouvement… mais pas de performance.
Et concrètement, ça donne quoi ?
Si vous avez déjà :
- Livré un dashboard qui n’est jamais utilisé
- Débattu pendant des semaines sur un KPI
- Ou reconstruit une solution quelques mois après sa mise en production
alors le problème n’était probablement pas technique.
Il était dans la façon dont le besoin a été défini.
Le vrai rôle de la prise de besoin
Une bonne prise de besoin ne consiste pas à écrire ce que le client demande.
Elle consiste à répondre à des questions beaucoup plus inconfortables :
- Quel objectif organisationnel voulons-nous atteindre?
- Quelle décision veut-on améliorer ?
- Quel comportement veut-on changer ?
- Quel indicateur doit évoluer ?
- Qu’est-ce qui va concrètement être différent après ?
Tant que ces réponses ne sont pas claires, il n’y a pas de projet.
Il n’y a qu’une intention.
Le rôle du conseiller : créer de la clarté, pas de la vitesse
C’est là que le rôle change complètement.
Un bon conseiller ne dit pas :
« Parfait, on va vous construire ça. »
Il dit :
« Pourquoi vous en avez besoin ? »
Et souvent :
« Êtes-vous certain que c’est la bonne approche ? »
Parce que dans la pratique :
- Les besoins sont ambigus
- Les objectifs sont implicites
- Les indicateurs sont mal définis
Et personne n’a vraiment pris le temps de les structurer.
Un besoin mal défini, c’est aussi un problème de données
Ce n’est pas seulement un problème de projet.
C’est aussi un problème de fondation :
- Des KPI mal définis
- Des indicateurs qui deviennent impossibles à réconcilier entre équipes
- Des chiffres qui ne veulent pas dire la même chose pour tout le monde
- Des règles de calcul implicites
- Des discussions interminables sur « le bon chiffre »
Et une fois que c’est implanté, c’est extrêmement difficile à corriger.
Dans la pratique, ça veut dire quoi ?
Dans la pratique, bien faire la prise de besoin, ça veut souvent dire :
- Ralentir un projet qui est déjà lancé
- Revenir sur une demande qui semble claire
- Poser des questions qui n’ont jamais été posées
C’est rarement confortable.
Mais c’est souvent là que la valeur se crée.
Chez ventriloc, c’est là qu’on met l’effort
Notre rôle n’est pas de livrer plus vite.
C’est de livrer quelque chose qui a du sens.
Concrètement, ça veut dire :
En gros, on ne te demandera pas « C’est quoi le KPI tu veux voir dans ton dashboard?
Parfois, ça mène à une solution différente.
Parfois, ça mène à un projet plus simple.
Et parfois, ça mène à ne pas faire le projet du tout.
La qualité versus la quantité, c’est un élément auquel on croit vraiment.
La majorité des erreurs sont invisibles
Le plus dangereux, c’est que les erreurs de prise de besoin ne sont pas visibles immédiatement.
Elles apparaissent plus tard :
- Un dashboard qui n’est pas utilisé
- Des chiffres qui ne sont pas crédibles
- Des décisions qui ne changent pas
Et là, on blâme :
- La technologie
- La donnée
- L’outil
Alors que le problème… était déjà là, dès le départ.
Construire moins, mais mieux
Une bonne prise de besoin ne sert pas à produire plus.
Elle sert à produire juste ce qu’il faut :
- Moins de solutions inutiles
- Moins de complexité
- Plus d’impact réel
Parce qu’un projet bien cadré :
- Va plus vite
- Coûte moins cher
- Crée de la valeur
- Et surtout, c’est le fun d’y contribuer!
En conclusion
On parle beaucoup de transformation numérique.
Mais on oublie souvent une chose simple :
La technologie ne crée pas de valeur par elle-même. Elle amplifie les décisions qui ont été prises avant.
Et ces décisions-là se prennent au moment de la prise de besoin.
C’est le seul moment où on peut encore éviter de faire un mauvais projet.
C’est là que le projet réussit…ou échoue.
Bien avant la première ligne de code générée par ton Agent IA.
