Un projet informatique échoue rarement parce que les équipes n’ont pas su faire. Il échoue parce que ce qu’on leur a demandé n’était pas ce qu’il fallait, et que personne ne l’a découvert avant le sixième mois. Les chiffres du secteur sont restés remarquablement stables depuis quinze ans, alors que l’outillage a été transformé de fond en comble. Ce n’est donc pas la technique qui pose problème.
Voxalia démarre, et ce constat est l’une des raisons pour lesquelles nous refusons certaines missions. Un prestataire qui accepte un besoin flou vend du temps, pas un résultat.
Quinze ans de chiffres qui ne bougent pas
Commençons par la mesure, parce qu’elle est têtue.
Le Standish Group, dans son CHAOS Report de 2015, mesurait 61 % de réussite sur les petits projets, 12 % sur les projets moyens et 6 % sur les grands, ces derniers échouant franchement dans 43 % des cas. McKinsey et l’université d’Oxford, sur plus de 5 400 projets étudiés en 2012, relevaient un dépassement moyen de 45 % du budget, de 7 % des délais, et une valeur livrée inférieure de 56 % à celle attendue, 17 % des grands projets menaçant l’existence même de l’entreprise. Le Project Management Institute situait en 2021 à 62 % la part des projets tenant leur budget et à 12 % les échecs francs. Le Boston Consulting Group estimait en octobre 2020 que 70 % des transformations numériques n’atteignent pas leurs objectifs.
Entre le premier et le dernier de ces travaux, presque tout a changé dans la manière de développer : les méthodes, l’industrialisation, le cloud, l’intégration continue, l’outillage de test. Le taux d’échec, lui, n’a pas suivi.
Une explication simple rend compte de cette stabilité : ces progrès portent sur la manière de construire, et le problème porte sur ce qu’on demande de construire.
Ce que la Cour des comptes a nommé, et qui vaut pour le privé
Le diagnostic le plus précis disponible en français ne vient pas du secteur privé, il vient d’un rapport public.
La Cour des comptes, dans son rapport de juillet 2023 sur le recours de l’État aux prestations intellectuelles de cabinets de conseil, relève quatre faiblesses côté donneur d’ordre : une évaluation insuffisante du besoin avant de recourir à un prestataire, un recours excessif aux accords-cadres sans cahier des charges rigoureux, une évaluation insuffisante des ressources internes disponibles, et l’absence quasi systématique d’évaluation après la mission.
Ces quatre points décrivent l’administration. Ils décrivent aussi, presque mot pour mot, ce que je vois dans des entreprises privées de toutes tailles. Un besoin qui n’a pas été évalué, des ressources internes dont on ignore la disponibilité réelle, un accord-cadre qui sert de cahier des charges, et aucune évaluation qui permettrait d’apprendre pour la fois suivante.
Le dernier point est le plus coûteux sur la durée. Une organisation qui n’évalue jamais ses prestations à leur clôture ne peut pas améliorer son cadrage, puisqu’elle ne sait pas ce qui a manqué la dernière fois.
Ce qu’un cadrage doit contenir
Six éléments, et aucun ne demande de compétence technique. Ils demandent des décisions.
Le problème, pas la solution. Un besoin exprimé sous forme de solution (« il nous faut un portail ») ferme la discussion avant qu’elle commence. Le même besoin exprimé sous forme de problème (« nos commerciaux ressaisissent trois fois la même donnée et nous perdons deux jours par semaine ») laisse ouvert le fait que la réponse soit peut-être une intégration, ou un changement de processus.
Ce qui se passe si on ne fait rien. C’est la question qui fait le plus de tri. Un projet dont personne ne sait décrire le coût de l’inaction est un projet qui n’a pas de commanditaire réel.
La mesure du succès, posée avant. Un critère chiffré, daté, et vérifiable par quelqu’un qui n’a pas travaillé sur le projet. Sans lui, le succès sera décrété ou contesté selon l’humeur du moment.
Le périmètre, et surtout ce qui en est exclu. Un cadrage sérieux contient une liste de ce qu’on ne fera pas. C’est la seule protection efficace contre l’élargissement progressif, et c’est le paragraphe que tout le monde saute.
Les contraintes réelles de l’existant. Les systèmes avec lesquels il faudra vivre, les flux à respecter, les données à reprendre. C’est là que se logent la majorité des surprises, et c’est la partie que le prestataire ne peut pas deviner, parce qu’elle n’est presque jamais documentée : elle vit dans la tête de quelques personnes, exactement comme la connaissance qu’aucune clause de réversibilité ne restitue.
La disponibilité des personnes. Combien de jours par semaine le métier peut-il réellement consacrer au projet, et qui décide en cas d’arbitrage. Un projet dont le référent métier est disponible deux heures par mois n’a pas besoin d’un prestataire, il a besoin d’un référent.
Trois signes qu’un besoin n’est pas cadré
Ces signes se repèrent en une réunion, et ils sont fiables.
Personne ne sait dire non. Demandez qui, nommément, peut refuser une demande d’une direction métier sur ce projet. Si la réponse est un comité, ou si elle n’existe pas, chaque demande sera acceptée et le périmètre grandira jusqu’à l’échec.
Le succès se décrit par une livraison et non par un effet. « Le portail sera en ligne en septembre » n’est pas un critère de succès, c’est une date. « Le temps de traitement d’un dossier passe de quatre jours à un jour d’ici décembre » en est un, parce qu’il peut être infirmé.
L’existant est décrit au futur. Quand les documents de cadrage parlent de ce que le système devra faire sans jamais décrire précisément ce qu’il fait aujourd’hui, c’est que l’analyse de l’existant n’a pas été faite. C’est le signe le plus fréquent et le plus coûteux, parce que la reprise de données et les interfaces représentent souvent la moitié de la charge réelle.
Ce que le prestataire ne fera pas à votre place
Il faut être honnête sur ce point, y compris quand cela dessert notre métier.
Un prestataire peut animer un cadrage, structurer les ateliers, écrire le document, challenger les hypothèses. Il ne peut pas prendre les décisions à votre place, et un cadrage est essentiellement une suite de décisions : ce qu’on exclut, ce qu’on accepte de ne pas avoir en version un, qui tranche entre deux directions métier qui ne veulent pas la même chose.
Il y a pire. Un prestataire a un intérêt économique à ce que le cadrage débouche sur une mission, ce qui crée un biais dont il faut avoir conscience des deux côtés de la table. La bonne pratique consiste à facturer le cadrage séparément et à accepter par écrit qu’il puisse conclure qu’il n’y a pas de projet, ou que le projet doit être fait autrement.
Un cadrage qui ne peut pas conclure « ne faites pas ce projet » n’est pas un cadrage, c’est une phase d’avant-vente déguisée.
Combien de temps, et à quel prix
La question qui vient toujours : combien de temps consacrer à cette étape avant de lancer ?
Il n’existe aucune règle sourcée, et je me méfie des ratios avancés avec assurance dans les conférences. Ce qui est mesurable, en revanche, c’est le coût du défaut de cadrage, et les chiffres cités plus haut donnent l’ordre de grandeur : un dépassement moyen de 45 % du budget sur les projets étudiés par McKinsey, et une valeur livrée inférieure de plus de moitié.
Le raisonnement pratique est donc le suivant. Un cadrage qui coûte quelques dizaines de jours face à un projet qui se compte en centaines n’a pas besoin de démontrer un retour sur investissement : il lui suffit d’éviter une seule erreur de périmètre pour être largement remboursé.
Le vrai obstacle n’est jamais budgétaire, il est politique. Un cadrage retarde le démarrage visible du projet, et dans beaucoup d’organisations, démarrer est ce qui se voit. C’est aussi la raison pour laquelle il faut le commander explicitement, avec un livrable et une date, plutôt que de compter sur le fait qu’il se fera tout seul.
Le cadrage détermine le mode contractuel, pas l’inverse
Une dernière conséquence, et elle est directement opérationnelle.
Le résultat d’un cadrage n’est pas seulement un document : c’est la réponse à la question du mode de contractualisation. Un besoin réellement stabilisé peut partir au forfait, avec un engagement de résultat qui a du sens. Un besoin encore mouvant appelle une régie pilotée. Un besoin flou n’appelle ni l’un ni l’autre, et c’est précisément ce que le choix entre régie et forfait recouvre.
Beaucoup d’organisations font l’inverse : elles choisissent le mode contractuel d’abord, souvent par habitude ou par politique achats, puis adaptent le cadrage à ce choix. Cela produit des forfaits signés sur des périmètres inconnus, et des régies ouvertes sur des besoins parfaitement spécifiables qui auraient dû être engagés.
Ce que nous en tirons
Nous créons Voxalia en proposant systématiquement un cadrage court et facturé quand le besoin qu’on nous présente n’est pas stabilisé, y compris lorsque le client nous demande directement un chiffrage au forfait.
Ce refus nous coûte des affaires, et je préfère le dire clairement plutôt que d’en faire un argument commercial. Un forfait signé sur un périmètre inconnu se termine mal pour les deux parties : le client obtient un résultat interprété au plus juste, et nous perdons de l’argent ou de la réputation, souvent les deux.
Notre engagement sur ce point est écrit : un cadrage que nous animons peut conclure qu’il ne faut pas faire le projet, ou qu’il faut le faire autrement que prévu, et nous facturons ce cadrage au même prix dans ce cas. Nous démarrons, et nous n’avons donc aucune réalisation à mettre en face de ce principe. Je préfère l’écrire ainsi plutôt qu’illustrer un propos avec des cas que nous n’avons pas encore livrés.
Vous pouvez lire qui nous sommes et d’où nous venons et ce que nous faisons en pilotage de projet avant de nous accorder le moindre crédit.
Questions fréquentes
Comment cadrer un besoin informatique avant de consulter un prestataire ?
Six éléments doivent être écrits, et aucun ne demande de compétence technique : le problème formulé comme un problème et non comme une solution, le coût de l’inaction, la mesure du succès posée avant le démarrage et vérifiable par un tiers, le périmètre assorti de la liste explicite de ce qui est exclu, les contraintes réelles de l’existant avec lequel il faudra vivre, et la disponibilité effective des personnes du métier ainsi que l’identité de celle qui tranche en cas d’arbitrage.
Peut-on demander à une ESN de cadrer le besoin ?
Oui, et c’est souvent utile, à trois conditions. Que le cadrage soit facturé séparément de la réalisation, faute de quoi il devient une phase d’avant-vente déguisée. Qu’il soit écrit noir sur blanc qu’il puisse conclure qu’il ne faut pas faire le projet, ou qu’il faut le faire autrement. Et que les décisions restent du côté du client, un prestataire pouvant animer, structurer et challenger, mais pas arbitrer entre deux directions métier à sa place.
Pourquoi les taux d’échec des projets informatiques ne baissent-ils pas ?
Parce que les progrès de ces quinze dernières années portent sur la manière de construire et non sur ce qu’on demande de construire. Les mesures disponibles le montrent : le Standish Group relevait en 2015 des taux de réussite de 61 % sur les petits projets et de 6 % sur les grands, le Project Management Institute situait en 2021 à 62 % la part des projets tenant leur budget, et le Boston Consulting Group estimait en 2020 que 70 % des transformations numériques n’atteignent pas leurs objectifs. La Cour des comptes, en juillet 2023, nomme la cause côté donneur d’ordre : une évaluation insuffisante du besoin avant de recourir à un prestataire.
Sources
- The Standish Group, CHAOS Report 2015, 2015 (61 % de réussite sur les petits projets, 12 % sur les projets moyens, 6 % sur les grands avec 43 % d’échec).
- McKinsey et université d’Oxford, Delivering large-scale IT projects on time, on budget, and on value, octobre 2012 (plus de 5 400 projets, dépassement de 45 % du budget et de 7 % des délais, valeur inférieure de 56 %, 17 % des grands projets menaçant l’existence de l’entreprise).
- Project Management Institute, Pulse of the Profession 2021, 2021 (62 % des projets dans le budget, 55 % dans les délais, 12 % d’échecs).
- Boston Consulting Group, Flipping the Odds of Digital Transformation Success, 29 octobre 2020 (70 % des transformations numériques n’atteignent pas leurs objectifs).
- Cour des comptes, Le recours par l’État aux prestations intellectuelles de cabinets de conseil, 10 juillet 2023 (évaluation insuffisante du besoin, accords-cadres sans cahier des charges rigoureux, évaluation insuffisante des ressources internes, absence quasi systématique d’évaluation après la mission).
