La démo s’est bien passée. C’est toujours le cas. Quelqu’un de votre équipe a branché un modèle, l’a pointé sur un vrai problème et a montré à une salle entière quelque chose qui fonctionnait vraiment. Personne, dans cette salle, n’a demandé à qui reviendrait l’outil dans dix-huit mois.
La question surgit plus tard, en général lors d’une réunion budgétaire, et elle sonne ainsi : construisons-nous cet outil correctement en code, ou le posons-nous sur une plateforme d’automatisation ? On la présente comme un choix technologique. Ce n’en est pas un.C’est une décision sur qui pourra ouvrir la chose quand elle cassera, sur ce qui se passera quand elle cassera à 3 heures du matin, et sur la capacité de quiconque à prouver qu’elle valait la peine d’être construite.
Le secteur regorge de chiffres sur la suite, et la plupart sont mal cités. Voici celui qui résiste à l’examen.
Sur 33 preuves de concept en IA lancées par une entreprise, quatre seulement sont passées en production.
La part des entreprises qui abandonnent la plupart de leurs initiatives d’IA est passée de 17 % à 42 % en un an, l’organisation moyenne mettant au rebut 46 % de ses preuves de concept avant la production.
Regardez ce que ces chiffres mesurent. Le premier compte les pilotes qui ne voient jamais le jour. Le second compte les programmes que l’on abandonne. Ni l’un ni l’autre ne dit que les modèles ont échoué. Lisez les analyses de causes profondes et le tableau est cohérent :la technologie a le plus souvent fonctionné, et l’organisation autour d’elle a échoué.
Plus de 80 % des projets d’IA échouent, soit environ le double du taux d’échec des projets informatiques sans IA.
La question du code contre la plateforme ne porte donc pas vraiment sur l’outillage. Elle porte sur celui de ces deux modes d’échec vers lequel vous avancez.
Deux colonnes, une décision
Le tableau masque la vraie décision, et c’est pourquoi le reste de cet article existe. Les deux colonnes vous donnent un outil fonctionnel d’ici vendredi. Une seule tourne encore l’an prochain, et laquelle dépend entièrement de vos réponses ci-dessous.
De quel côté penche le vôtre ?
Répondez ci-dessous pour prendre un relèvement
Un repère, pas la réponse. Le raisonnement est dans les quatre questions ci-dessous.
1Qu’est-ce qui est en jeu quand elle casse ?
2À qui appartient-elle dans dix-huit mois ?
3À quelle fréquence, et combien ?
4Qui décide ?
Quatre questions, dans l’ordre
La plupart des versions de cette décision se présentent sous forme de liste de contrôle. Une liste laisse croire que les points pèsent tous pareil. Ce n’est pas le cas.Celles-ci sont classées pour que la première question offrant une réponse tranchée close le débat, et vous pouvez alors cesser de lire.
Commencez ici, car cette question prime sur toutes les suivantes.
Un projet perso sur un serveur inutilisé, qui ne touche ni données client ni argent : votre tolérance au risque est presque illimitée. Construisez-le de la manière la plus rapide pour vous. Rien d’autre dans cet article ne vous concerne, et vous devriez cesser de lire pour aller le construire.
Un processus dans une entreprise réglementée, qui touche aux dossiers clients ou déplace de l’argent : les questions se multiplient aussitôt. L’outil peut-il envoyer, ou seulement lire ? Une erreur est-elle réversible ? Une panne fera-t-elle du bruit, ou restera-t-elle silencieuse pendant six semaines ? Qui peut voir les identifiants ? Et celle qui tranche la plupart de ces projets :la sécurité validera-t-elle quelque chose qu’elle ne peut pas inspecter ?
L’IA relève l’enjeu d’une manière bien précise. Moins le chemin de décision est visible, plus le risque grimpe, quel que soit le support de construction. Quand les conséquences sont réelles, il faut que les décisions de l’IA soient journalisées, encadrées et lisibles par quelqu’un qui n’était pas dans la salle au moment de la conception. C’est faisable en code. C’est simplement un travail que la plupart des équipes ne budgètent pas, et ce travail reste le même quelle que soit la colonne choisie.
Un processus qui s’arrête et crie est réparé dès mardi. Ce n’est pas celle qu’il faut craindre.
réparée dès mardiUn champ renommé, une API en expiration, un modèle qui renvoie des absurdités plausibles, et rien nulle part ne le signale.
tourne cinq semainesD’où la question de 3 heures du matin, car les choses cassent bien à 3 heures du matin. La panne à redouter n’est pas la bruyante. Un processus qui s’arrête et crie est réparé dès mardi. La panne coûteuse est la silencieuse : un champ renommé, une API en expiration, un modèle qui se met à renvoyer des absurdités plausibles, et rien nulle part ne le signale. Celle-là tourne cinq semaines, et quand quelqu’un finit par s’en apercevoir, un quart de vos données est faux. Les tentatives de reprise, les alertes et un journal que quelqu’un lit vraiment ne sont pas des fonctions que l’on ajoute après le lancement. Ce sont elles qui séparent une automatisation d’un passif, et ce sont les premières que l’on sacrifie quand le calendrier dérape.
Cette question change la réponse plus souvent que toute autre, et c’est celle que les dirigeants sont les mieux placés pour trancher, car elle n’a rien de technique.
Si le concepteur et le mainteneur sont la même personne pour toujours, choisissez le plus rapide. Sinon, vous avez un problème de passation, etc’est sur les passations que meurent les automatisations. Il y a ici trois rôles distincts, aux besoins différents :
Qui la construit
Un développeur dispose de toutes les options. Un profil marketing ou opérations n’a qu’un seul chemin pour devenir concepteur, et il passe par quelque chose qu’il peut voir.
Qui la maintient
Un an plus tard, une API change ou un prompt demande un réglage. Si cette personne n’a pas construit l’outil, elle doit pouvoir l’ouvrir et le comprendre en un après-midi. Un flux visuel se lit par quelqu’un qui n’aurait jamais su en écrire l’équivalent en code. Ce n’est pas une propriété mineure.
Qui la modifie
Un seuil plus élevé que la compréhension. Un collègue non technique peut-il remplacer un identifiant ou modifier une planification sans ouvrir un ticket ? Si chaque petit changement passe par une seule personne technique, celle-ci devient le goulet d’étranglement de toute la fonction, et finit en pratique par détester ce qu’elle a construit.
Le test de passation est brutal : si la personne qui a construit l’outil partait le mois prochain, survivrait-il ? Ce qu’un collègue peut ouvrir et suivre survit. Un code que seul son auteur comprenait continue de tourner jusqu’au jour où il casse, et plus personne ne veut y toucher.
Un point d’actualité mérite d’être nommé. Le code généré se produit vite, et souvent personne, pas même celui qui l’a demandé, n’en a un modèle mental complet. La question de la maintenance ne disparaît pas parce que le code a été bon marché à écrire. Elle se durcit, car la défense habituelle (l’auteur se souvient du pourquoi) ne tient plus.
Ce sont en réalité deux questions, qui appellent des réponses distinctes.
La fréquence commande le coût. L’arithmétique n’a rien de compliqué. Un processus déterministe exécuté 500 fois par jour ne coûte presque rien par exécution. La même tâche confiée à un modèle qui raisonne 500 fois par jour coûte 500 appels de modèle quotidiens, pour toujours, et redécide ce que vous aviez déjà décidé. Si vous pouvez écrire des règles couvrant tous les cas, écrivez les règles. Payer un modèle pour les redériver n’est pas qu’un gaspillage : cela ouvre la porte à une réponse différente à l’exécution 79.
La taille de la flotte est la question que personne ne pose avant qu’il soit trop tard. Votre première automatisation peut vivre n’importe où. Votre quarantième, non. Dès que des dizaines tournent en parallèle, il vous faut un seul endroit qui les montre toutes, ce qui a tourné, ce qui a échoué, et un moyen de relancer l’échec une fois corrigé. Ce besoin arrive d’un coup, et l’installer après coup sur quarante scripts faits main est un projet à part entière. C’est la raison la plus fréquente pour laquelle les organisations se standardisent sur une couche d’orchestration, et elle n’a rien à voir avec la supériorité de telle ou telle automatisation prise isolément.
Voici maintenant ce que les éditeurs de plateformes préféreraient que vous découvriez plus tard. La plupart des outils d’orchestration se facturent à l’exécution, à la tâche ou à l’utilisateur, et le palier qui inclut la gouvernance dont vous avez réellement besoin (journaux d’audit, accès par rôle, déploiement privé) est rarement celui par lequel on commence. Modélisez un processus exécuté 500 fois par jour sur la grille tarifaire de votre candidat avant de vous engager, puis modélisez-le à 5 000, car c’est le second chiffre qui met fin à la relation. L’auto-hébergement change cette arithmétique et introduit un autre coût : vous exploitez désormais la plateforme aussi.
Il existe un plafond plus dur que le prix. Les plateformes conviennent jusqu’au jour où votre logique cesse d’entrer dans leurs cases, et le mode d’échec n’est pas un mur : c’est une lente accumulation de contournements, un nœud de code ici, un webhook vers un service annexe là, jusqu’à ce que vous mainteniez un système distribué dessiné dans le produit d’un autre. Si votre processus a une vraie complexité algorithmique, ce jour arrive tôt. Et votre porte de sortie mérite d’être chiffrée dès le départ : exporter un flux est facile, exporter l’environnement d’exécution dont il dépendait ne l’est pas, et « pas de verrouillage » est une promesse à tester plutôt qu’à croire.
Aucun nom de produit ici, à dessein. Toute liste restreinte écrite aujourd’hui aura été rebattue le temps que vous la lisiez, et les questions ci-dessus leur survivent toutes. Quels que soient les outils retenus, appliquez le même test : construisez-y un vrai processus, puis confiez-le à quelqu’un qui ne l’a pas construit et observez ce qui se passe.
En dernier, car c’est la plus intéressante et la moins décisive. C’est la question par laquelle tout le monde commence. C’est aussi pourquoi tant de ces projets finissent au mauvais endroit.
Aucun jugement
Déplacer chaque facture de la boîte mail vers le stockage, de la même façon, chaque jour. Rendez le processus déterministe et cessez d’y penser.
Du jugement de bout en bout
Recherche, rédaction, nettoyage d’un jeu de données brouillon et ponctuel. C’est vous qui pilotez, chaque étape dépend de votre lecture de la précédente. Il s’agit d’une session d’agent avec vous dans la boucle, et l’habiller d’un processus n’ajoute que de la lourdeur.
Une décision au cœur de la répétition
Cinq cents tickets de support par jour arrivent de la même façon et se dirigent de la même façon, et quelqu’un doit lire chacun d’eux pour décider de son sujet. Ce quelqu’un peut être un modèle, placé à une étape visible au milieu d’une structure par ailleurs déterministe.
Et la sous-question que l’on saute : à quel moment la décision se prend-elle ? Il y a un large écart entre un modèle qui rédige une réponse qu’un humain valide et un modèle qui l’envoie. Si un humain valide, ce point de contrôle fait partie de votre processus et doit rester visible, quel que soit ce que vous construisez.
Où cela atterrit le plus souvent
Quatre questions, et la plupart des gens trouvent que l’une d’elles règle tout avant même d’atteindre les autres.
La logique sur mesure est le vrai produit
Le code. Une plateforme n’a rien à y faire
Réglementé, en contact client, argent ou confiance en jeu
La plateforme, chaque décision de l’IA encadrée et auditée
Des dizaines d’automatisations, et ça continue
La plateforme, quelle que soit l’allure de chacune prise isolément
Partagé en deux
Partagez le travail : la partie déterministe en flux, la partie de jugement en étape d’IA à l’intérieur
L’arbitrage oppose la vélocité à la réversibilité. Quand le risque de perte est faible, la vélocité l’emporte, et cela oriente vers le code. À mesure que ce risque grandit, pouvoir voir et défaire ce qui s’est passé prime sur la vitesse, et cela oriente vers une plateforme. La plupart des organisations se situent au milieu, et c’est pourquoi la réponse est si souvent « les deux ». Ce n’est pas une esquive. Le partage tombe en général à un endroit précis : le squelette récurrent est un flux, et l’unique étape qui demande du jugement est un appel de modèle en son sein, là où vous pouvez le surveiller.
Personne ne sait de combien il va plus vite
En février 2026, un organisme de recherche à but non lucratif a publié un billet expliquant que son résultat le plus cité ne décrivait plus la réalité, et que le chiffre de remplacement qu’il proposait ne méritait guère plus de confiance. C’est ce que cet article contient de plus utile, et presque personne parmi ceux qui citent l’original ne s’en est aperçu.
Commençons par le résultat lui-même :
Des développeurs expérimentés ont mis 19 % de temps en plus pour accomplir de vraies tâches lorsqu’ils pouvaient utiliser des outils d’IA, tout en estimant après coup que l’IA les avait rendus 20 % plus rapides.
On l’a cité partout comme la preuve que les outils d’IA pour le code ne fonctionnent pas. On le cite encore ainsi ce mois-ci. Mais METR a refait l’expérience avec des outils plus récents et a publié ses conclusions.
Pour le sous-ensemble des développeurs d’origine ayant participé à l’étude ultérieure, nous estimons désormais un gain de vitesse de 18 %. Parmi les développeurs nouvellement recrutés, le gain estimé est de 4 %.
Ils sont allés plus loin en signalant le résultat d’origine comme périmé sur sa propre page, dans un encadré rouge, au-dessus du résumé.
Deux conséquences en découlent. D’abord, quiconque cite aujourd’hui le chiffre de 19 % comme actuel cite quelque chose que les auteurs ont retiré en tant que description des conditions présentes. Voilà un test simple et efficace pour savoir si un prestataire lit au-delà des titres. Ensuite, et c’est plus utile : les développeurs de cette première étude se trompaient de 39 points de pourcentage sur leur propre productivité, dans le sens qui les flattait. C’étaient des gens expérimentés, travaillant sur un code qu’ils connaissaient bien.
Votre équipe n’y échappe pas. Nous non plus. C’est pourquoi la réponse à « est-ce plus rapide ? » ne se donne jamais à main levée. C’est une mesure prise avant de commencer, puis reprise après, par la même méthode, les deux dates notées.
Écrivez d’abord le critère d’arrêt
Chaque décision qui précède suppose que cet outil devrait exister. Parfois, il ne le devrait pas, et le moment d’en décider, c’est maintenant, tant que tout le monde est encore optimiste, car c’est le seul moment où un critère d’arrêt peut s’écrire honnêtement.
Avant de choisir une colonne, écrivez le résultat qui signifie que vous arrêtez. Pas « si ça ne marche pas ». Un chiffre, assorti d’une date. La forme est toujours la même, en trois volets :
Un seuil de qualité
Précision de routage sous X à la sixième semaine.
Un plafond de coût
Plus de Y par exécution une fois le volume réel atteint.
Un test de passation
Personne hors de l’équipe de conception ne l’a ouvert à la quatrième semaine.
Vos chiffres ne seront pas les nôtres. Ce qui compte, c’est qu’ils existent, par écrit, avant que quiconque ne soit attaché à la réponse.
C’est le troisième que l’on omet le plus souvent, et c’est lui qui prédit le mieux. Si la seule personne capable d’ouvrir l’outil est celle qui l’a construit, vous n’avez pas appris qu’il vous faut plus de temps d’ingénierie. Vous avez appris la réponse à la question deux, et aucune ingénierie supplémentaire n’y remédie.
Ce que la recherche ci-dessus établit est plus étroit que ce qu’on lui fait souvent dire. IDC attribue le ratio de 33 pour 4 à la maturité organisationnelle : données, processus, infrastructure. RAND pointe la direction et la communication. Personne, dans ces travaux, ne dit « personne n’avait le droit d’arrêter ». Cette part-là est notre lecture, tirée de nos propres missions, et nous la signalons comme telle : les projets que nous avons vus engloutir le plus de budget étaient rarement ceux qui échouaient vite. C’étaient ceux sans définition convenue de l’échec, qui dérivaient jusqu’à ce qu’un dirigeant, à bout de patience, annule le programme entier plutôt que le seul mauvais pari qu’il contenait.Un arrêt défendable coûte moins cher qu’un abandon lent, et le conseil qui vous a vu arrêter proprement un projet approuve le suivant plus vite.
Répondez donc soigneusement à la question de l’outil. Elle compte. Répondez simplement d’abord à l’autre, par écrit, tant que tout le monde croit encore que le projet va réussir : que faudrait-il pour que nous arrêtions ? Si personne ne veut coucher cette phrase sur le papier, l’outil que vous choisirez ne vous sauvera pas.