Pourquoi payer une agence, maintenant qu'un développeur sort une application en une semaine avec un assistant ?

Points clés de cet article :

• Dans votre entreprise, personne n'est extérieur : celui qui animerait l'atelier dépend des gens qu'il devrait contredire en séance.
• Depuis 1994, l'industrie a plus que doublé son taux de projets livrés dans les temps et dans le budget. L'ampleur des dépassements, elle, n'a pas bougé.
• Un petit projet réussit dans 61 % des cas, un très gros dans 6 %.
• Nos experts techniques sont nos product owners : le même individu anime l'atelier, tranche l'architecture et écrit le code.
• Le périmètre s'écrit en deux colonnes, et chaque ligne de la colonne des exclusions porte une date de réexamen.
• C'est notre processus, celui qu'on applique sur chaque projet : un atelier de deux heures, deux pages qui ferment la discussion.

Parce que les projets ratent avant le code.

Le Project Management Institute, qui forme et certifie les chefs de projet dans le monde entier, a interrogé plus de deux mille praticiens sur ce qui fait rater un projet. Sur ceux qui manquent leurs objectifs, 47 % les manquent à cause des exigences : mal recueillies, mal écrites, mal tenues dans le temps.

Produire du logiciel n'a jamais été aussi rapide. Une maquette fonctionnelle sort en une soirée, un premier écran en une heure, une API en dix minutes. Cette accélération ne touche pas les 47 %.

Brooks l'écrivait dans No Silver Bullet en 1986, et rien depuis ne l'a démenti : la partie la plus difficile de la construction d'un système logiciel est de décider précisément quoi construire. Aucune autre partie du travail conceptuel n'est aussi difficile, aucune n'estropie autant le résultat si elle est mal faite, aucune n'est plus difficile à rectifier ensuite.

Le cadrage est l'exercice qui traite cette partie-là. Il ne consomme pas des semaines. Il consomme quelques heures, à condition de savoir ce qu'on y cherche.

Où sont allés trente ans de progrès

Ce que l'industrie a réglé : en 1994, le premier CHAOS Report du Standish Group trouvait 16,2 % de projets livrés dans les temps, dans le budget et avec le contenu prévu, et 31,1 % abandonnés en cours de route. Dans l'édition 2015, sur la même définition, la réussite atteint 36 % et les abandons tombent à 19 %. Livrer du logiciel s'est appris.

Ce qui n'a pas suivi : l'argent et la valeur. McKinsey et le centre de recherche sur les grands projets de l'université d'Oxford, sur plus de 5 400 grands projets informatiques en 2012, ceux dont le budget initial dépasse quinze millions de dollars : 45 % de dépassement de budget en moyenne, et 56 % de valeur en moins que prévu. Flyvbjerg et son équipe, sur 5 392 projets informatiques dans 66 pays, dans une étude parue en 2022, mesurent un coût réel valant en moyenne 1,8 fois le coût estimé. Surtout, ils vérifient sur les treize années que couvrent leurs données que l'ampleur des dépassements ne varie pas de façon statistiquement significative.

Cette moyenne de 1,8 se lit mal si on s'arrête là. La médiane est à 1,0 : la moitié des projets tient son estimation, et les dépassements sont à peu près aussi fréquents que les économies. Ce qui fait le 1,8, c'est une minorité qui dérape sans plafond. Les catastrophes ne sont pas des accidents isolés, elles forment la queue régulière d'une loi de puissance.

Le progrès a donc porté sur l'exécution : livrer plus vite, plus souvent, avec moins d'abandons. Il n'a pas porté sur la décision de ce qu'on construit, et c'est là que se situent les 47 %.

L'IA accélère l'axe qui allait déjà mieux. Elle supprime la barrière du budget de développement, donc des projets se lancent sans être cadrés, puisque la partie chère a disparu. Et elle raccourcit le délai jusqu'au premier écran : on a le sentiment d'avancer bien avant de savoir si on construit la bonne chose. Aucune mesure n'existe encore sur l'issue des projets à l'ère des assistants de code. Notre pari est que l'écart entre ce qu'on livre et ce qui sert va se creuser.

Ce qu'une agence apporte quand coder ne coûte presque plus rien

Vous pouvez écrire l'application en interne. Quelqu'un d'équipé sort un écran par jour, et la question technique est réglée.

Reste le travail d'avant. Votre direction administrative, votre responsable production et vos commerciaux décrivent trois processus différents et attendent trois outils différents. Aucun des trois n'est le chef des deux autres. La réunion se termine, chacun repart avec sa version, et le projet démarre sur la moyenne des trois.

Une équipe interne travaille avec un handicap sur cet exercice : elle est partie prenante. Elle connaît l'existant au point de ne plus le questionner, elle a ses propres habitudes de travail à défendre, et elle dépend hiérarchiquement des gens qu'elle devrait contredire en séance.

La cause, pas le symptôme : dans la même enquête du PMI, 37 % des organisations citent un recueil d'exigences inexact comme cause première d'échec, devant le budget, les délais et les compétences techniques. C'est la première ligne du classement, et c'est la seule que personne n'achète.

C'est ce travail que nous vendons. Réunir les parties prenantes dans la même pièce, poser les questions qui fâchent, écrire ce que l'entreprise fait aujourd'hui et ce qu'elle veut faire de son organisation ensuite, puis en sortir un périmètre que chacun reconnaît. Ensuite seulement on construit, que ce soit la conception d'une nouvelle application métier ou un accompagnement du MVP au produit.

Nos experts techniques sont nos product owners

Le métier de développeur, au sens de quelqu'un qui reçoit une spécification et la traduit en code, n'a plus de valeur marchande. Cette partie se fait vite, et elle se fait avec une machine.

Ce qui a pris de la valeur, c'est le même individu à un autre poste. Nos experts techniques animent l'atelier au lieu d'attendre la spécification. Ils vont s'asseoir à côté de la personne qui saisit les commandes et la regardent travailler pendant une heure. Ils demandent d'où vient la marge, ce que coûte une erreur de saisie, qui décide quand deux services ne sont pas d'accord. Ils tranchent l'architecture le même jour. Ils écrivent ce qui ne sera pas fait, et le défendent devant le comité qui voulait tout.

La compétence technique est ce qui rend l'arbitrage crédible. Quand un responsable demande une synchronisation en temps réel avec l'ERP, quelqu'un qui sait la construire dit en séance ce qu'elle vaut, ce qu'elle interdira ensuite, et quelle version dégradée rend le même service pour une fraction du prix. Un chef de projet qui ne code pas ne peut pas tenir cette phrase, et un prestataire qui code sans mandat d'arbitrage ne la dira pas.

Prendre de la hauteur, ici, veut dire se rapprocher du métier. C'est aussi ce qui nous permet d'intervenir en équipe produit externalisée : la chaîne complète entre la réunion et la base de données tient dans la même équipe.

Jusqu'où va un cadrage

Un malentendu tenace veut que cadrer signifie tout prévoir avant de commencer. C'est l'inverse. Cadrer, c'est se donner les moyens d'avancer d'un état au suivant en décidant à chaque étape, avec assez d'information pour que la décision suivante soit meilleure que la précédente.

Détailler des exigences qui ont peu de chances d'être construites ne protège de rien et se paie deux fois : une fois à l'écriture, une fois à la réécriture. La question qui décide tient en une ligne : avons-nous écrit ce qui empêche de se tromper sur les six prochaines semaines.

Un cadrage réussi produit un document qu'une personne extérieure peut lire et dont elle sait dire, devant une demande nouvelle, si elle est dedans ou dehors. Il s'écrit aussi bien sur un existant que sur une page blanche : quand l'application est déjà là et que plus personne n'ose y toucher, l'atelier sert à décider ce qu'on garde avant d'engager une reprise et modernisation.

D'où vient la marge de votre entreprise

C'est l'étape que personne ne documente.

Avant de parler de fonctionnalités, il faut savoir d'où vient l'argent. Quelle activité rapporte, laquelle coûte, laquelle est subie. Qui décide d'un achat chez le client, et sur quel critère. Ce qui se passerait si le projet n'existait pas du tout.

Ces réponses changent tout ce qui suit. Un outil qui fait gagner deux heures par semaine à une équipe de trois personnes ne vaut pas la même chose selon qu'il accélère la facturation ou la production d'un rapport que personne ne lit. La même fonctionnalité, décrite dans les mêmes termes, se priorise différemment selon ce qu'on a compris à cette étape.

Ce que ça déplace : quand la réponse fait apparaître que la marge se joue sur le délai de réponse au client, le premier lot cesse d'être le CRM demandé au départ. Il devient un configurateur d'aide à la vente, qui met les règles de chiffrage entre les mains du commercial pendant le rendez-vous.

Une équipe technique excellente livre exactement ce qu'on lui demande. Quand personne ne lui dit quoi demander, elle décide à la place du métier, sans avoir vu un utilisateur travailler. C'est le mécanisme le plus courant du gaspillage, et il ne se corrige pas en recrutant de meilleurs profils.

À qui ça sert, quel problème, pourquoi ils paient

Avant la base de données, avant le choix de la technologie, ces trois réponses écrites.

L'exercice paraît trivial jusqu'au moment où on l'écrit. La plupart des projets trébuchent sur la dernière. « Parce que c'est plus pratique » n'est pas une réponse. « Parce qu'ils passent aujourd'hui quatre heures par mois à recopier des données d'un outil à l'autre, et que ces quatre heures sont facturables » en est une.

Si le pitch ne tient pas en trois phrases, ce n'est pas un problème de rédaction. C'est que la cible ou le problème ne sont pas encore choisis.

Les utilisateurs et leurs freins

Pour chaque personne qui utilisera l'outil : ce qu'elle vient y faire, ce qu'elle y gagne, et ce qui l'empêcherait de s'en servir.

La dernière colonne est celle qui sert. Un profil sans frein identifié est une hypothèse, pas un utilisateur observé. Le commercial qui doit saisir ses visites le soir depuis son téléphone a un frein réel, et ce frein décide de l'ergonomie du formulaire bien plus sûrement qu'un atelier de conception.

Passé quatre ou cinq profils, l'exercice devient un catalogue. Réduire force à choisir qui compte, et ce choix est une décision de produit.

Prérequis d'atelier : les participants doivent parler la même langue avant d'entrer dans la pièce. Quand la moitié de la salle découvre en séance ce qu'un modèle sait faire, on passe deux heures à cadrer des fantasmes. C'est à ça que servent nos conférences de sensibilisation et la formation IA opérationnelle, qui part des tâches que vos équipes font tous les jours.

Le périmètre en deux colonnes

Une page. À gauche, ce que la première version fait. À droite, ce qu'elle ne fera pas.

La colonne de gauche s'écrit toute seule, et personne n'a besoin d'aide pour la remplir. La colonne de droite manque dans la plupart des documents de cadrage qu'on nous montre. C'est elle qui tient le budget quand les demandes reviennent une par une.

Chaque ligne se formule du point de vue de celui qui s'en sert, jamais en termes techniques : « le commercial retrouve un client par son nom » plutôt que « recherche full-text sur la table contacts ». Chaque exclusion porte une date de réexamen, sans quoi la colonne se vide en trois semaines : les demandes reviennent, chacune paraît minuscule, et personne ne se souvient qu'elle avait été écartée. Et la colonne de droite doit finir au moins aussi longue que celle de gauche. Tant qu'elle est plus courte, l'exercice n'a pas été fait.

La mesure qui justifie la colonne de droite : sur la plateforme d'expérimentation de Microsoft, une idée sur trois seulement améliore la métrique qu'elle était censée améliorer. Kohavi, qui a dirigé cette plateforme, précise que le taux tombe encore sur un produit déjà optimisé. On ne sait pas à l'avance ce qui marche : ce que le périmètre écrit permet, c'est de couper les mauvaises idées avant de les avoir payées en entier.

Une application partie vite, sans périmètre tenu, finit avec des fonctionnalités que personne n'utilise et un code que personne ne maîtrise. C'est le point de départ d'un Rescue IA.

Découper en lots courts

Qu'est-ce qui part en premier, et comment saura-t-on dans six semaines que c'était le bon choix.

La deuxième moitié de la question est celle qu'on oublie. Un premier lot sans critère de réussite ne produit pas d'information : il produit une livraison, et la discussion recommence à zéro.

Le chiffre qui décide du découpage : le même CHAOS Report range ses projets par taille. Les petits réussissent à 61 % et échouent à 7 %. Les très gros réussissent à 6 % et échouent à 43 %. Aucun autre facteur mesuré ne pèse autant sur l'issue, et le cabinet en tire lui-même la conséquence : découper un gros projet en plusieurs petits est la première recommandation qu'il fait à ses clients.

C'est aussi la conclusion que Flyvbjerg tire de sa propre base, vingt ans de projets tous domaines confondus, dans Make Megaprojects More Modular : les projets qui tiennent sont ceux qu'on peut construire en répétant un module, et les autres paient leur taille. Boehm et Basili écrivaient dès 2001, dans leur Software Defect Reduction Top 10 List, que les projets logiciels consacrent 40 à 50 % de leur effort à des reprises évitables. Les auteurs ajoutent une réserve qu'il faut garder en tête, parce qu'elle décrit ce qu'un bon cadrage cherche à préserver : une partie du travail de reprise est inévitable, et les changements qui rendent un système plus rentable ne doivent pas être découragés en les classant comme des défauts.

Le découpage a une conséquence qu'on oublie de chiffrer : chaque lot mis en service commence à rembourser. Un lot livré en six semaines paie pendant que le suivant s'écrit, ce qui suppose que quelqu'un le maintienne en état de marche, du code jusqu'au serveur. C'est l'objet de notre offre d'exploitation et d'optimisation des applications.

Les décisions qui bloquent

La dernière section du document liste ce qui n'est pas décidé, et nomme la personne qui décidera.

C'est elle qui fait la différence entre un projet qui avance et un projet qui attend. Une équipe qui attend trois jours une réponse a perdu trois jours, quelle que soit sa productivité, et ces jours ne figurent dans aucun tableau de bord.

Ce que coûte l'attente : Flyvbjerg, Holm et Buhl ont mesuré en 2004, sur 258 projets d'infrastructure, que chaque année écoulée entre la décision de construire et la mise en service ajoute en moyenne 4,64 points de dépassement budgétaire. Le délai n'est pas neutre pendant qu'on attend une réponse : il se paie.

Une question utile à poser en fin d'atelier : qu'est-ce qui bloque aujourd'hui, et depuis combien de jours. Le temps que met la réponse à venir se note aussi. Quand personne dans l'entreprise n'a le mandat de trancher ces sujets, c'est le rôle que nous tenons en direction technique à temps partagé.

L'IA dans un cadrage

Un modèle remplit un document de cadrage en quelques minutes. Le résultat est présentable et structuré. Il est faux sur les deux points qui coûtent : les exclusions et la marge.

Il travaille bien sur la matière qu'on lui donne : reformuler un pitch dicté de travers, produire une première liste d'utilisateurs à corriger, lister les cas limites qu'on n'avait pas vus, récupérer les règles métier d'une application existante en lisant son code. Sur ce dernier terrain il est le plus utile, et c'est rarement là qu'on l'emploie.

Il invente la colonne de droite. Un modèle est conçu pour satisfaire : il ne dit jamais qu'une fonctionnalité ne sert à rien, il ne refuse jamais un périmètre, il ne relève jamais que la demande d'hier contredit celle d'aujourd'hui. Sa liste d'exclusions est plausible et générique, et elle ne protège de rien parce qu'elle ne reflète aucun arbitrage réel. Il invente aussi la marge : il ne sait pas d'où vient l'argent dans une entreprise qu'il n'a pas questionnée, et il produira une réponse crédible plutôt que de dire qu'il ne sait pas.

La règle de relecture : tout ce qu'un modèle écrit et qui n'a été contredit par personne est une hypothèse, pas une décision.

Trier ensuite les usages de l'IA qui méritent un budget est un exercice à part, que nous menons comme un diagnostic et une feuille de route IA, avant toute mise en place d'agents connectés au système d'information. Si vos équipes travaillent déjà avec des modèles pendant le cadrage, deux sujets se posent en même temps : où elles déposent les documents internes, ce que couvre un espace de travail IA sécurisé, et ce que vous pourrez prouver ensuite, ce que couvre la gouvernance et la conformité IA.

Ce qui sort de l'atelier

Ce qu'on écrit tient sur deux pages :

• Le problème, en une phrase.
• Qui le vit, et à quelle fréquence.
• Ce que la première version fait.
• Ce qu'elle ne fera pas, avec une date de réexamen par ligne.
• Comment on saura que c'était le bon choix.
• Ce qui reste à trancher, et qui décide.

Rien de plus. Au-delà de deux pages, le document cesse d'être un outil de décision et devient un livrable à valider.

L'atelier, en deux heures, sur votre projet

Nous menons l'exercice chez vous, avec vos contraintes et les gens qui décident. Vous repartez avec vos pages remplies, que la suite se fasse avec nous ou sans nous.

Deux de nos offres sont sorties de ce même atelier mené sur notre propre activité : la relance des relations LinkedIn et CRM et le Content Studio. Dans les deux cas, ce qui a fait le produit n'est pas le code, c'est l'arbitrage sur ce que la machine propose et ce qu'un humain valide avant publication.

Pour préparer l'atelier, nous avons écrit la partie amont dans notre guide sur la cartographie des processus métier, et ce qu'il faut regarder avant de confier le chantier dans celui sur le choix d'une agence digitale.