Code ou plateforme ? La décision qui suit le POC.

La démo s’est bien passée. Elles se passent toujours bien. Un membre de votre équipe a branché un modèle sur un vrai problème et montré à une salle comble quelque chose qui marchait pour de bon. Personne, ce jour-là, n’a demandé qui en aurait la charge dans dix-huit mois.

La question surgit plus tard, le plus souvent en réunion budgétaire, et se formule ainsi : faut-il le développer proprement en code, ou le monter sur une plateforme d’automatisation ? On la présente comme un choix technologique. Elle n’en est pas un. Il s’agit de décider qui pourra ouvrir l’outil quand il cassera, ce qui se passera s’il casse à 3 h du matin, et si quelqu’un pourra seulement prouver qu’il méritait d’être construit.

Les chiffres sur la suite ne manquent pas, et la plupart sont cités de travers. Voici celui qui résiste à l’examen.

Sur 33 preuves de concept d’IA lancées par une entreprise, seules quatre sont arrivées en production.

IDC avec Lenovo, d’après CIO · mars 2025

En une seule année, la part des entreprises renonçant à la plupart de leurs initiatives d’IA est passée de 17 % à 42 %, l’organisation moyenne abandonnant 46 % de ses preuves de concept avant la mise en production.

S&P Global Market Intelligence · Voice of the Enterprise, octobre 2025

Voyez ce que mesurent ces chiffres. Le premier recense les pilotes jamais mis en service, le second les programmes abandonnés. Aucun ne dit que les modèles ont échoué. Les études sur les causes profondes dressent un tableau constant : la technologie a le plus souvent tenu, c’est l’organisation autour d’elle qui a lâché.

Plus de 80 % des projets d’IA échouent, un taux d’échec à peu près double de celui des projets informatiques sans IA.

RAND Corporation · Root Causes of Failure for AI Projects, 2024

Développer ou passer par une plateforme : la question ne relève donc pas vraiment de l’outillage. Elle revient à savoir vers lequel de ces deux échecs vous marchez.

Deux colonnes, une seule décision

Ce tableau masque la vraie décision, d’où la suite de cet article. Les deux colonnes livrent un outil qui fonctionne d’ici vendredi. Une seule tiendra encore l’an prochain, et laquelle, cela dépend entièrement de vos réponses ci-dessous.

De quel côté penche votre projet ?

Sur la page en ligne, une boussole interactive convertit quatre penchants en une position de l’aiguille. Vous trouverez ci-dessous les mêmes quatre questions, avec le côté vers lequel penche chaque réponse.

1. Que risque-t-on en cas de panne ?
   • Penche vers le code : un projet personnel, sans données clients ni argent en jeu
   • Penche vers la plateforme : secteur réglementé ou argent en jeu (dossiers, paiements, confiance)
2. Qui en sera responsable dans dix-huit mois ?
   • Penche vers le code : son auteur le conserve, et ce sera toujours lui
   • Penche vers la plateforme : quelqu’un d’autre, une passation s’annonce
3. Quelle fréquence, et combien d’automatisations ?
   • Penche vers le code : une seule, ponctuelle, votre première automatisation
   • Penche vers la plateforme : toute une flotte, des dizaines, à haute fréquence
4. Qui décide ?
   • Penche vers le code : des règles fixes, aucun jugement nécessaire
   • Penche vers la plateforme : un modèle dans une boucle, du jugement au cœur de la répétition

Quatre questions, dans l’ordre

Ce choix se présente le plus souvent sous forme de liste de contrôle. Or une liste laisse entendre que tous les critères pèsent autant. Il n’en est rien. Ces questions sont classées de sorte que la première à appeler une réponse nette clôt le débat : vous pouvez alors cesser de lire.

Que coûte un dérapage ?

Commencez par celle-ci : elle prime sur toutes les autres.

Un projet personnel sur un serveur inutilisé, sans données clients ni argent en jeu : votre tolérance au risque est quasi illimitée. Construisez-le de la façon qui vous fait aller le plus vite. Le reste de cet article ne vous concerne pas ; refermez-le et mettez-vous au travail.

Un processus au sein d’une entreprise réglementée, qui touche aux dossiers clients ou fait circuler de l’argent : aussitôt, les questions se multiplient. L’outil peut-il envoyer, ou seulement lire ? Une erreur se rattrape-t-elle ? Une panne fera-t-elle du bruit, ou restera-t-elle muette six semaines durant ? Qui a accès aux identifiants ? Et celle qui tranche le sort de la plupart de ces projets : la sécurité donnera-t-elle son feu vert à ce qu’elle ne peut pas inspecter ?

L’IA alourdit l’enjeu d’une façon bien précise : moins le cheminement de la décision est visible, plus le risque grandit, quel que soit le socle retenu. Dès que les conséquences sont réelles, les décisions de l’IA doivent être journalisées, encadrées et compréhensibles par quelqu’un qui n’était pas là quand l’outil a été conçu. Le code le permet. Simplement, la plupart des équipes ne prévoient pas ce travail au budget, et ce travail reste le même quelle que soit la colonne choisie.

• La panne bruyante : un processus qui s’arrête et sonne l’alarme est réparé d’ici mardi. Ce n’est pas elle qu’il faut redouter. (réparée d’ici mardi)
• La panne silencieuse : un champ renommé, une API qui ne répond plus à temps, un modèle qui renvoie des absurdités plausibles, et rien, nulle part, ne le signale. (dure cinq semaines)

D’où la question des 3 h du matin, puisque les pannes surviennent bel et bien à 3 h du matin. Celle qu’il faut redouter n’est pas la panne bruyante : un processus qui s’arrête et sonne l’alarme est réparé d’ici mardi. La panne qui coûte cher, c’est la panne silencieuse : un champ renommé, une API qui ne répond plus à temps, un modèle qui se met à produire des absurdités plausibles, et rien, nulle part, ne le signale. Celle-là dure cinq semaines, et le jour où quelqu’un s’en rend compte, un quart de vos données est faux. Nouvelles tentatives automatiques, alertes et journal réellement lu ne sont pas des fonctionnalités à ajouter après le lancement. Ce sont eux qui séparent une automatisation d’un passif, et ce sont les premiers sacrifiés quand le calendrier dérape.

Qui en sera responsable dans dix-huit mois ?

Aucune autre question ne fait basculer la réponse aussi souvent, et les dirigeants sont les mieux placés pour y répondre, car elle n’a rien de technique.

Si le concepteur et le mainteneur restent à jamais une seule et même personne, prenez le plus rapide. Sinon, vous avez un problème de passation, et c’est à la passation que les automatisations viennent mourir. Trois rôles distincts entrent ici en jeu, avec des besoins différents :

1. Qui le construit : un développeur dispose de toutes les options. Pour une personne du marketing ou des opérations, il n’existe qu’une seule voie pour construire quoi que ce soit, et elle passe par un outil qu’elle peut voir.
2. Qui le maintient : un an plus tard, une API change ou un prompt demande un réglage. Si cette personne n’est pas celle qui l’a construit, elle doit pouvoir l’ouvrir et le comprendre en un après-midi. Un workflow visuel se lit sans savoir écrire son équivalent en code. L’atout n’a rien de négligeable.
3. Qui le modifie : l’exigence va au-delà de la compréhension. Un collègue sans profil technique peut-il changer un identifiant ou modifier une planification sans passer par un ticket ? Si la moindre retouche doit transiter par une seule personne technique, celle-ci devient le goulet d’étranglement de tout le service, et finit en pratique par prendre en grippe l’outil qu’elle a construit.

Le test de passation est brutal : si son auteur partait le mois prochain, l’outil lui survivrait-il ? Ce qu’un collègue peut ouvrir et suivre survit. Le code que seul son auteur comprenait tourne jusqu’au jour où il casse, et plus personne ne veut alors s’en approcher.

Une subtilité très actuelle mérite d’être signalée. Le code généré s’obtient vite, et bien souvent personne, pas même celui qui l’a demandé au modèle, n’en a une compréhension complète. Que le code ait peu coûté à écrire ne fait pas disparaître la question de la maintenance. Elle s’en trouve même aiguisée, car le garde-fou habituel (l’auteur se souvient du pourquoi) ne tient plus.

À quelle fréquence l’outil tourne-t-il, et combien en avez-vous ?

Il y a là en réalité deux questions, qui appellent chacune sa réponse.

C’est la fréquence qui fait le coût, et le calcul est simple. Un processus déterministe exécuté 500 fois par jour ne coûte presque rien à chaque passage. Confiez la même tâche à un modèle qui raisonne 500 fois par jour, et vous payez 500 appels quotidiens, indéfiniment, pour trancher de nouveau une question déjà réglée. Si des règles peuvent couvrir tous les cas, écrivez ces règles. Payer un modèle pour les reconstituer n’est pas seulement du gaspillage : c’est s’exposer à une réponse différente à la 79e exécution.

La taille de la flotte, personne ne s’en soucie avant qu’il soit trop tard. Votre première automatisation peut vivre n’importe où. La quarantième, non. Dès que des dizaines tournent en parallèle, il faut un endroit unique qui les montre toutes : ce qui a tourné, ce qui a échoué, et un moyen de relancer une exécution ratée une fois le problème corrigé. Ce besoin surgit du jour au lendemain, et l’installer après coup sur quarante scripts maison est un chantier à part entière. C’est la raison la plus fréquente pour laquelle les organisations adoptent une couche d’orchestration commune, et elle n’a rien à voir avec les mérites propres de telle ou telle automatisation.

Vient ensuite ce que les éditeurs de plateformes préféreraient vous voir découvrir plus tard. La plupart des outils d’orchestration facturent à l’exécution, à la tâche ou à la licence utilisateur, et l’offre qui inclut la gouvernance réellement nécessaire (journaux d’audit, contrôle d’accès par rôle, déploiement privé) est rarement celle sur laquelle on démarre. Avant de vous engager, simulez sur la grille tarifaire du candidat un processus exécuté 500 fois par jour, puis 5 000 fois, car c’est le second chiffre qui met fin à la relation. L’auto-hébergement change la donne mais ajoute un autre coût : il vous faut désormais exploiter aussi la plateforme.

Il existe une limite plus dure que le prix. Une plateforme fait l’affaire tant que votre logique tient dans ses cases ; ensuite, on ne heurte pas un mur, on accumule lentement les contournements : un nœud de code ici, un webhook vers un service annexe là, jusqu’au jour où vous entretenez un système distribué qui se trouve simplement dessiné dans le produit d’un autre. Si votre processus présente une vraie complexité algorithmique, ce jour arrive tôt. Chiffrez aussi votre porte de sortie dès le départ : exporter un workflow est facile, exporter l’environnement d’exécution dont il dépendait l’est beaucoup moins, et l’argument « aucun verrouillage » est à éprouver, pas à prendre pour argent comptant.

Aucun nom de produit ici, et c’est voulu. Toute présélection dressée aujourd’hui sera rebattue d’ici à ce que vous la lisiez ; les questions ci-dessus, elles, resteront valables. Quels que soient les outils retenus, appliquez le même test : construisez-y un vrai processus, confiez-le à quelqu’un qui n’a pas participé à sa construction, et regardez ce qui se passe.

Qui décide : les règles, le modèle ou une personne ?

Elle arrive en dernier, car c’est la plus intéressante et la moins décisive. Tout le monde commence pourtant par elle, et c’est pour cela que tant de ces projets finissent au mauvais endroit.

• Les règles : aucun jugement. Transférer chaque facture de la boîte mail vers l’espace de stockage, de la même manière, tous les jours. Rendez le processus déterministe, puis n’y pensez plus.
• Une personne : du jugement de bout en bout. Recherche, rédaction, nettoyage d’un jeu de données ponctuel et désordonné. Vous tenez la barre, et chaque étape dépend de la lecture que vous faites de la précédente. C’est une session avec un agent, vous dans la boucle, et l’enfermer dans un processus n’ajoute que de la lourdeur.
• Le modèle : une décision au cœur de la répétition. Cinq cents tickets d’assistance arrivent chaque jour par le même canal et empruntent le même circuit, mais il faut que quelqu’un lise chacun d’eux pour en déterminer l’objet. Ce quelqu’un peut être un modèle, installé à une étape visible au milieu d’une structure par ailleurs déterministe.

Reste la sous-question qu’on oublie : quand la décision est-elle prise ? Un modèle qui rédige une réponse soumise à l’approbation d’un humain diffère profondément d’un modèle qui l’envoie lui-même. Si un humain approuve, ce point de contrôle fait partie de votre processus et doit apparaître dans ce que vous construisez.

Le verdict le plus fréquent

Quatre questions, et la plupart des lecteurs s’aperçoivent que l’une d’elles règle tout avant même d’aborder les autres.

Tout se joue entre vitesse et réversibilité. Quand l’enjeu est faible, la vitesse prime, et la balance penche vers le code. À mesure qu’il grandit, pouvoir voir et défaire ce qui s’est passé compte davantage que la vitesse, et la balance penche vers une plateforme. La plupart des organisations se trouvent entre les deux, d’où la fréquence de la réponse « les deux ». Ce n’est pas une dérobade. La ligne de partage passe généralement à un endroit précis : l’ossature récurrente est un workflow, et la seule étape qui demande du jugement est un appel de modèle placé à l’intérieur, là où vous pouvez le surveiller.

Personne ne sait vraiment ce qu’il gagne en vitesse

En février 2026, un organisme de recherche à but non lucratif a publié un billet pour expliquer que son résultat le plus cité ne décrivait plus la réalité, et que le chiffre proposé à la place ne méritait guère plus de confiance. C’est l’information la plus utile de cet article, et presque aucun de ceux qui citent l’étude d’origine ne s’en est aperçu.

Partons du résultat lui-même :

Retiré par ses auteurs, février 2026

Autorisés à utiliser des outils d’IA, des développeurs expérimentés ont mis 19 % de temps en plus à accomplir des tâches réelles, tout en estimant après coup que l’IA les avait rendus 20 % plus rapides.

Essai contrôlé randomisé de METR · juillet 2025 · 16 développeurs, 246 tâches

Le chiffre a été repris partout comme la preuve que les assistants de code à base d’IA ne marchent pas. Il circule encore ainsi ce mois-ci. Or METR a refait l’expérience avec des outils plus récents, et publié ses résultats.

Parmi les développeurs de l’étude initiale ayant pris part à la suivante, nous estimons désormais le gain de vitesse à 18 %. Chez les développeurs nouvellement recrutés, il est estimé à 4 %.

METR · février 2026, sur des outils de fin 2025

METR est allé plus loin : sur la page même de l’étude, un encadré rouge placé au-dessus du résumé signale désormais le résultat initial comme dépassé.

Une même étude, deux chiffres qui auraient dû concorder :

• Vitesse ressentie : +20 %
• Vitesse mesurée : −19 %
• Écart en leur faveur : 39 pts

Deux leçons s’en dégagent. D’abord, quiconque présente aujourd’hui les 19 % comme un chiffre d’actualité invoque un résultat que ses propres auteurs ne tiennent plus pour une description de la situation présente. Voilà un test peu coûteux et efficace pour savoir si un fournisseur lit plus loin que les titres. Ensuite, et c’est plus instructif : les développeurs de la première étude se sont trompés de 39 points de pourcentage sur leur propre productivité, et dans le sens qui les flattait. Il s’agissait de professionnels chevronnés, travaillant sur du code qu’ils connaissaient bien.

Votre équipe n’y échappe pas. Nous non plus. Voilà pourquoi on ne répond jamais à « est-ce plus rapide ? » à main levée, mais par une mesure prise avant de commencer, répétée à l’identique après, selon la même méthode, avec les deux dates consignées.

Écrire d’abord le critère d’arrêt

Toutes les décisions qui précèdent partent du principe que cet outil doit exister. Ce n’est pas toujours le cas, et c’est maintenant qu’il faut le vérifier, tant que l’optimisme règne encore : c’est le seul moment où l’on peut rédiger un critère d’arrêt en toute honnêteté.

Avant de choisir une colonne, consignez par écrit le résultat qui vous fera arrêter. Pas « si ça ne marche pas » : un chiffre, assorti d’une date. Il prend toujours la même forme, en trois critères :

1. Un plancher de qualité : une précision du routage inférieure à X à la sixième semaine.
2. Un plafond de coût : plus de Y par exécution, une fois les volumes réels atteints.
3. Un test de passation : à la quatrième semaine, personne hors de l’équipe de développement ne l’a ouvert.

Vos chiffres ne seront pas les nôtres. Ce qui compte, c’est qu’ils existent, par écrit, avant que quiconque ait misé quoi que ce soit sur la réponse.

Le troisième est le plus souvent escamoté, et c’est pourtant le plus révélateur. Si seule la personne qui l’a construit sait l’ouvrir, ce que vous venez d’apprendre n’est pas qu’il faut davantage de temps de développement. Vous tenez la réponse à la deuxième question, et aucun supplément d’ingénierie n’y remédiera.

C’est la phase Cap d’AZIMUTH, la méthode exposée sur la page Méthode. Les clients y résistent plus qu’à toute autre, jusqu’à la première fois où elle leur fait économiser un trimestre.

Les travaux cités plus haut établissent moins qu’on ne leur fait dire d’habitude. IDC impute le rapport de 33 à 4 à la maturité de l’organisation : données, processus, infrastructure. RAND met en cause la direction et la communication. Nulle part dans ces travaux on ne lit « personne n’avait le droit d’arrêter ». Cela, c’est notre lecture, tirée de nos missions, et nous la présentons comme telle : les projets que nous avons vus engloutir le plus de budget étaient rarement ceux qui échouaient vite. C’étaient ceux qui n’avaient aucune définition commune de l’échec, et qui dérivaient jusqu’à ce qu’un dirigeant perde patience et supprime le programme tout entier plutôt que le seul mauvais pari qu’il abritait. Un arrêt défendable coûte moins cher qu’un lent abandon, et le conseil d’administration qui vous a vu arrêter proprement un projet approuve plus vite le suivant.

Traitez donc la question de l’outillage avec soin : elle compte. Simplement, répondez d’abord à l’autre, par écrit, tant que chacun croit encore à la réussite du projet : qu’est-ce qui devrait se produire pour que nous arrêtions ? Si personne ne veut écrire cette phrase noir sur blanc, l’outil choisi ne vous sauvera pas.

Dernière relecture : juillet 2026. Ces pages sont relues tous les trimestres, et chaque correction est consignée, jamais faite en silence. Si un chiffre a vieilli, c’est un bogue : signalez-le à hello@bearingbridge.com.