La question que se posent les acheteurs
Les dirigeants qui achètent du développement se posent une question nouvelle. Si l’IA écrit une grande partie du code, pourquoi payer encore une agence, un studio ou un freelance au prix d’avant ?
La question est légitime. Et la réponse honnête n’est pas « parce que l’IA ne sait pas coder ». Elle code, de mieux en mieux. La réponse est que le code n’a jamais été la partie la plus chère d’un projet raté.
Ce qui fait rater un projet n’a jamais été le code
En 2012, McKinsey et le centre de gestion des grands programmes de l’université d’Oxford ont analysé plus de 5 400 projets informatiques. Sur les grands projets, ceux dont le budget initial dépassait 15 millions de dollars, le constat est connu : 45 % de dépassement de budget, 7 % de retard, et 56 % de valeur livrée en moins que prévu.
Le plus intéressant est dans les causes. Les auteurs les rangent en quatre familles : un manque de focus, c’est-à-dire des objectifs flous ou déconnectés du métier ; des exigences qui changent en cours de route et une complexité technique mal anticipée ; des équipes mal alignées ou sans les bonnes compétences ; des calendriers irréalistes.
Aucune de ces causes n’est « les développeurs tapaient trop lentement ».
Le Standish Group, qui suit des dizaines de milliers de projets depuis les années 1990, dit la même chose autrement. Dans son rapport CHAOS 2020, 31 % des projets réussissent, 50 % aboutissent avec des dépassements ou un périmètre réduit, et 19 % échouent. Et la taille pèse lourd : les petits projets réussissent bien plus souvent que les grands.
L’IA agit sur le coût de production du code. Les causes d’échec, elles, sont en amont et autour. Elles sont intactes.
Ce qui perd de la valeur
Soyons clairs sur ce qui change, y compris pour nous.
Le temps de développement pur, facturé à la journée, perd de la valeur. Un écran standard, un formulaire, une intégration d’API documentée : ce travail se fait plus vite qu’avant, et un client le sait. Un freelance ou un studio dont l’offre se résume à « je transforme une maquette en code » se retrouve en concurrence avec un outil à vingt dollars par mois.
La régie pure perd aussi de son sens. Quand le client paie le temps passé, il n’a aucun intérêt à ce que l’IA fasse gagner du temps à son prestataire, et le prestataire n’a aucun intérêt à le lui faire gagner. Le modèle économique va contre l’outil.
Enfin, la maquette comme livrable perd de sa valeur. Un porteur de projet peut aujourd’hui générer lui-même un prototype cliquable. Ce prototype est utile, mais il n’est pas un produit.
Ce qui garde de la valeur
Trancher le périmètre. Décider ce qui entre dans la première version et ce qui attend. Dire non à une fonctionnalité séduisante qui doublerait le délai. C’est la première cause d’échec selon McKinsey, et c’est un travail de jugement, pas de production. Plus le code devient rapide, plus il devient tentant de tout construire, et plus ce rôle compte.
Concevoir une architecture qui tiendra. Choisir comment les données sont organisées, comment le web et le mobile partagent le même socle, ce qui devra encaisser les évolutions des trois prochaines années. Un assistant de code résout le ticket qu’on lui donne. Il ne choisit pas la structure dans laquelle les cent tickets suivants devront entrer.
Connaître le métier du client. Sur une plateforme de sous-traitance dans le BTP, savoir qu’une entreprise doit vérifier les papiers d’un artisan dès 5 000 euros de contrat, puis tous les six mois. Sur une plateforme de praticiens, savoir qu’un profil ne doit pas apparaître tant que ses assurances ne sont pas vérifiées. Ces règles ne sont pas dans le code. Elles sont dans le métier, et il faut les aller chercher.
Répondre du résultat. C’est le point le plus sous-estimé. Un outil ne signe pas de contrat. Quand le produit ne fait pas ce qui était prévu, il faut quelqu’un qui en répond. C’est la vraie ligne de partage entre un prestataire qui vend du temps et un prestataire qui vend un résultat.
Ce que ça change pour ceux qui achètent
Trois questions à poser à un prestataire en 2026.
Comment facturez-vous ? Si c’est au temps passé, demandez comment les gains de l’IA vous reviennent. Un prix arrêté à l’avance transfère ce gain au bon endroit : le prestataire a intérêt à travailler vite, et le client connaît son coût.
Qui décide de l’architecture, et comment ? Si la réponse est vague, le produit sera construit ticket par ticket, et la facture arrivera au moment de la première grosse évolution.
Sur quoi vous engagez-vous ? Un nombre de jours, ou un produit qui fonctionne à une date donnée ?
Ce que nous en avons fait chez Tiltio
Nous avons tiré les conséquences de ce déplacement dans notre offre.
Nos projets tiennent en quatre mois, avec un périmètre, un délai et un prix arrêtés avant la première ligne de code. Le format court n’est pas un argument commercial : c’est ce que disent les données du Standish Group sur la taille des projets, et c’est ce qui oblige à trancher le périmètre au lieu de le laisser dériver.
Nous nous engageons sur le résultat, et nous tenons cet engagement depuis deux ans. Il repose sur un suivi serré et une collaboration au quotidien avec le client, pas sur des jours facturés.
Nos équipes sont resserrées autour de trois rôles, décrits dans notre article sur les cloisons du produit : la valeur pour le client, la solidité du système, la qualité de l’expérience. L’IA absorbe la documentation, le code répétitif et une partie du recettage. L’énergie humaine reste sur ce qui garde de la valeur : décider, concevoir, vérifier.
Et quand un projet est encore flou, nous commençons par un audit sprint de trois à cinq jours, pour cadrer avant de s’engager. Quand un produit existe déjà, un audit technique de reprise dit s’il est réparable ou à refaire.
Ce modèle a une limite, et nous la connaissons : il ne convient pas aux projets dont le client ne veut pas arbitrer. Un prix arrêté suppose un périmètre arrêté.
Pour conclure
L’IA n’a pas rendu les studios et les freelances inutiles. Elle a rendu inutile la partie de leur travail qui se mesurait en lignes de code. Ce qui reste est plus exigeant et plus rare : savoir quoi construire, comment le faire tenir, et en répondre. Les prestataires qui vendront cela s’en sortiront mieux qu’avant. Ceux qui continueront à vendre des jours verront leur prix baisser au rythme des outils.
Questions fréquentes
L’IA va-t-elle remplacer les agences de développement ? Elle remplace une partie de la production de code, pas le cadrage, l’architecture ni l’engagement sur le résultat. Les causes d’échec des projets identifiées par McKinsey et Oxford (objectifs flous, exigences changeantes, équipes mal alignées, calendriers irréalistes) ne dépendent pas de la vitesse d’écriture du code.
Pourquoi les projets informatiques échouent-ils ? D’après l’étude McKinsey et Oxford de 2012 sur plus de 5 400 projets, les grands projets dépassent leur budget de 45 % et livrent 56 % de valeur en moins que prévu, principalement à cause d’objectifs flous et d’exigences qui changent. Le rapport CHAOS 2020 du Standish Group ne compte que 31 % de projets réussis.
Faut-il choisir un prestataire au forfait ou en régie ? Avec l’IA, un prix arrêté aligne mieux les intérêts : le prestataire gagne à travailler vite et le client connaît son coût. La régie a du sens quand le périmètre ne peut vraiment pas être défini à l’avance.
Que doit vendre un freelance développeur en 2026 ? Moins du temps de développement, davantage de la décision : cadrage du périmètre, choix d’architecture, connaissance d’un métier précis, et un engagement sur un résultat plutôt que sur un nombre de jours.
Sources
McKinsey et université d’Oxford, « Delivering large-scale IT projects on time, on budget, and on value », 2012
Standish Group, CHAOS 2020: Beyond Infinity