Code ou plateforme ? Le choix qui suit le POC.

La démo s’est bien passée, comme toujours. Quelqu’un de l’équipe a branché un modèle sur un problème réel et présenté devant une salle pleine un outil qui fonctionnait pour de bon. Personne dans la salle n’a demandé qui s’en occuperait dans dix-huit mois.

La question revient plus tard, souvent en réunion budgétaire, sous cette forme : faut-il développer l’outil proprement en code, ou le confier à une plateforme d’automatisation ? On la présente comme un choix technologique. C’est tout autre chose. Il s’agit de savoir qui pourra ouvrir l’outil quand il tombera en panne, ce qui se passera si la panne survient à 3 h du matin, et si quelqu’un pourra seulement prouver qu’il méritait d’être construit.

Sur la suite, les chiffres abondent, et la plupart sont cités de travers. En voici un qui résiste à l’examen.

Sur 33 preuves de concept d’IA lancées par une entreprise, quatre seulement ont atteint la production.

IDC avec Lenovo, cité par CIO · mars 2025

En un an, la part des entreprises qui renoncent à la plupart de leurs projets d’IA est passée de 17 % à 42 %, et l’organisation moyenne abandonne 46 % de ses preuves de concept avant la mise en production.

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

Notez ce que mesurent ces chiffres. Le premier compte les pilotes jamais déployés, le second les programmes abandonnés. Ni l’un ni l’autre ne dit que les modèles ont échoué. Les études sur les causes d’échec convergent : la technologie a globalement tenu, c’est l’organisation autour qui a lâché.

Plus de 80 % des projets d’IA échouent, soit environ deux fois plus que les projets informatiques sans IA.

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

Trancher entre code et plateforme n’est donc pas vraiment une affaire d’outils. Il s’agit de savoir lequel de ces deux échecs vous guette.

Deux colonnes, un seul choix

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

De quel côté penchez-vous ?

Sur la page en ligne, une boussole interactive traduit quatre penchants en une position de l’aiguille. Voici les quatre mêmes questions, avec l’orientation de chaque réponse.

1. Quel est l’enjeu en cas de panne ?
   • Côté code : un projet personnel, sans données clients ni argent
   • Côté plateforme : secteur réglementé ou argent en jeu (dossiers, paiements, confiance)
2. Qui en a la charge dans dix-huit mois ?
   • Côté code : son auteur le garde, à vie
   • Côté plateforme : quelqu’un d’autre, une passation se profile
3. À quelle fréquence, et combien ?
   • Côté code : une seule, ponctuelle, votre première automatisation
   • Côté plateforme : toute une flotte, des dizaines, à haute fréquence
4. Qui décide ?
   • Côté code : des règles fixes, aucun jugement requis
   • Côté plateforme : un modèle dans une boucle, du jugement au sein de la répétition

Quatre questions, dans cet ordre

On présente presque toujours ce choix sous forme de liste de contrôle. Or une liste laisse croire que tous les critères se valent. Il n’en est rien. Ces questions sont classées de sorte que la première à apporter une réponse nette clôt le débat : inutile alors de lire la suite.

Que coûte un raté ?

Commencez par là : cette question prime sur toutes les autres.

Un projet personnel sur un serveur de récupération, sans données clients ni argent en jeu : votre tolérance au risque est presque sans limite. Faites comme vous allez le plus vite. Le reste de cet article ne vous concerne pas : arrêtez de lire et mettez-vous au travail.

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

Avec l’IA, l’enjeu monte d’une manière bien particulière. Plus le cheminement de la décision est opaque, plus le risque grandit, quelle que soit la technologie retenue. Dès que les conséquences sont réelles, les décisions de l’IA doivent être journalisées, bornées et compréhensibles par quelqu’un qui n’était pas là lors de leur conception. Le code en est capable. Simplement, la plupart des équipes ne prévoient pas ce travail au budget, et il reste le même quelle que soit la colonne choisie.

• La panne bruyante : un processus qui s’arrête en donnant l’alerte est réparé d’ici mardi. Ce n’est pas elle qu’il faut craindre. (réparée d’ici mardi)
• La panne silencieuse : un champ renommé, une API qui expire, un modèle qui renvoie des absurdités vraisemblables, et nulle part le moindre signal. (dure cinq semaines)

D’où la question des 3 h du matin, car 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 en donnant l’alerte est réparé d’ici mardi. La panne coûteuse, c’est la panne silencieuse : un champ renommé, une API qui expire, un modèle qui se met à renvoyer des absurdités vraisemblables, et nulle part le moindre signal. Celle-là dure cinq semaines, et le jour où quelqu’un s’en aperçoit, un quart de vos données sont fausses. Les nouvelles tentatives, les alertes et un journal que quelqu’un lit vraiment ne sont pas des fonctionnalités à ajouter après le lancement. Ce sont elles qui distinguent une automatisation d’un passif, et ce sont les premières sacrifiées quand le calendrier glisse.

Qui en a la charge dans dix-huit mois ?

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

Si celui qui construit et celui qui maintient restent à jamais la même personne, prenez le plus rapide. Sinon, vous avez un problème de passation, et c’est à la passation que meurent les automatisations. Trois rôles distincts entrent en jeu, chacun avec ses propres besoins :

1. Qui le construit : un développeur a toutes les options. Pour une personne du marketing ou des opérations, il n’existe qu’une voie pour construire quoi que ce soit, et elle passe par quelque chose qu’elle peut voir.
2. Qui le maintient : un an plus tard, une API change ou un prompt doit être retouché. Si cette personne ne l’a pas construit, il lui faut pouvoir l’ouvrir et le comprendre en un après-midi. Un workflow visuel reste lisible pour quelqu’un qui n’aurait jamais su en écrire l’équivalent en code. L’atout est loin d’être mineur.
3. Qui le modifie : l’exigence dépasse la simple compréhension. Un collègue non technicien peut-il remplacer un identifiant ou changer une planification sans passer par un ticket ? Si la moindre modification transite par une seule personne technique, celle-ci devient le goulet d’étranglement de tout le service et, en pratique, finit par prendre en grippe l’outil qu’elle a construit.

Le test de passation est sans appel : si la personne qui l’a construit 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 y toucher.

Une subtilité, très actuelle, mérite d’être relevée. Le code généré s’obtient vite, et souvent personne, pas même l’auteur du prompt, n’en a une représentation mentale complète. Que le code n’ait presque rien coûté à écrire ne fait pas disparaître la question de la maintenance. Elle s’en trouve aggravée, car la parade habituelle (l’auteur se souvient pourquoi) ne fonctionne plus.

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

Il y a là deux questions, qui appellent chacune leur réponse.

La fréquence fait le coût. Le calcul est simple. Un processus déterministe exécuté 500 fois par jour ne coûte pratiquement rien par exécution. La même tâche confiée à un modèle qui raisonne 500 fois par jour, c’est 500 appels de modèle quotidiens, sans fin, pour rejouer chaque fois une décision déjà prise. Si vous pouvez rédiger des règles qui couvrent tous les cas, rédigez-les. Payer un modèle pour les reconstruire n’est pas seulement du gaspillage : c’est courir le risque d’une réponse différente à la 79e exécution.

La taille de la flotte, personne n’y pense avant qu’il ne 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 vous faut un endroit unique qui les montre toutes, avec ce qui a tourné, ce qui a échoué, et un moyen de relancer l’échec une fois corrigé. Ce besoin surgit du jour au lendemain, et le greffer après coup sur quarante scripts maison est un projet à part entière. C’est de loin la raison la plus fréquente pour laquelle les organisations adoptent une couche d’orchestration commune, et cela n’a rien à voir avec les mérites de telle ou telle automatisation une fois installée dessus.

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

Le prix n’est pas la limite la plus dure. Une plateforme donne satisfaction tant que votre logique tient dans ses cases, et le jour où elle n’y tient plus, on ne bute pas contre un mur : les contournements s’accumulent lentement, un nœud de code ici, un webhook vers un service annexe là, jusqu’à ce que vous entreteniez un système distribué qui se trouve dessiné dans le produit de quelqu’un d’autre. Si votre processus comporte une vraie complexité algorithmique, ce jour vient 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 « sans enfermement » est une promesse à vérifier, pas à croire sur parole.

Aucun nom de produit ici, et c’est voulu. Toute liste 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 vient en dernier, car c’est la plus intéressante et la moins déterminante. C’est pourtant par elle que tout le monde commence, et c’est pour cela que tant de ces projets atterrissent au mauvais endroit.

• Les règles : aucun jugement. Déplacer chaque facture de la messagerie vers le stockage, de la même manière, tous les jours. Rendez le processus déterministe et 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, chaque étape dépend de la lecture que vous faites de la précédente. C’est une session avec un agent, où vous restez 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 de support arrivent chaque jour par le même canal et suivent le même circuit, mais quelqu’un doit lire chacun d’eux et déterminer son objet. Ce quelqu’un peut être un modèle, placé à une étape visible au milieu d’une structure déterministe pour le reste.

Reste la sous-question qu’on oublie : à quel moment la décision est-elle prise ? Entre un modèle qui rédige une réponse soumise à la validation d’un humain et un modèle qui l’envoie lui-même, l’écart est considérable. Si un humain valide, ce point de contrôle fait partie du processus et doit être visible dans ce que vous construisez.

Là où penche la balance

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

Tout est affaire d’arbitrage entre vitesse et réversibilité. Quand le risque est limité, la vitesse l’emporte, et cela plaide pour le code. À mesure que le risque grandit, pouvoir voir et défaire ce qui s’est passé compte davantage que la vitesse, et cela plaide pour une plateforme. La plupart des organisations se situent entre les deux, d’où la fréquence de la réponse « les deux ». Ce n’est pas une dérobade. La frontière 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ù on peut le surveiller.

Personne ne sait vraiment s’il va plus vite

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

Commençons par le résultat lui-même :

Retiré par ses auteurs, février 2026

Des développeurs expérimentés ont mis 19 % de temps en plus pour accomplir des tâches réelles lorsqu’ils pouvaient utiliser des outils d’IA, tout en estimant ensuite 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 outils de codage par IA ne servent à rien. Il l’est encore ce mois-ci. Mais METR a renouvelé l’expérience avec des outils plus récents et publié ses résultats.

Pour le sous-ensemble des développeurs initiaux ayant participé à l’étude suivante, nous estimons désormais une accélération de 18 %. Parmi les développeurs nouvellement recrutés, l’accélération estimée est de 4 %.

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

L’organisme est allé plus loin en signalant le résultat initial comme dépassé sur sa propre page, dans un encadré rouge, au-dessus du résumé.

Une même étude, deux chiffres qui auraient dû coïncider :

• Ressenti, plus rapide : +20 %
• Mesuré, plus lent : −19 %
• Écart, en leur faveur : 39 pts

Deux leçons s’en dégagent. D’abord, quiconque cite aujourd’hui les 19 % comme un chiffre d’actualité invoque un résultat dont les auteurs eux-mêmes disent qu’il ne décrit plus la situation actuelle. Voilà un test rapide et efficace pour savoir si un fournisseur lit plus loin que les gros titres. Ensuite, et c’est plus utile : 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. C’étaient des professionnels chevronnés, qui travaillaient sur du code qu’ils connaissaient bien.

Votre équipe n’est pas à l’abri. Nous non plus. Voilà pourquoi la réponse à « est-ce plus rapide ? » ne se donne jamais à main levée. C’est une mesure prise avant de commencer, puis répétée 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 supposent que cet outil a lieu d’exister. Parfois, ce n’est pas le cas, et c’est maintenant qu’il faut le déterminer, tant que l’optimisme règne encore, car c’est le seul moment où l’on peut rédiger honnêtement un critère d’arrêt.

Avant de choisir une colonne, écrivez le résultat qui vous fera arrêter. Pas « si ça ne marche pas » : un chiffre, assorti d’une date. Le format comporte toujours les trois mêmes volets :

1. Un plancher de qualité : une précision de routage inférieure à X à la sixième semaine.
2. Un plafond de coût : plus de Y par exécution une fois le volume réel atteint.
3. Un test de passation : à la quatrième semaine, personne en dehors de l’équipe de développement ne l’a ouvert.

Vos chiffres ne seront pas les nôtres. L’essentiel est qu’ils existent, par écrit, avant que quiconque ait misé sur la réponse.

Le troisième est le plus souvent omis, et c’est lui qui en dit le plus. Si la seule personne capable de l’ouvrir est celle qui l’a construit, vous n’avez pas découvert qu’il fallait davantage de temps de développement. Vous tenez la réponse à la deuxième question, et aucun effort d’ingénierie supplémentaire n’y remédiera.

C’est la phase de cap (Bearing) de la méthode AZIMUTH, décrite sur la page Méthode. C’est aussi celle que les clients contestent le plus, jusqu’au jour où elle leur épargne un trimestre perdu.

Les travaux cités plus haut établissent moins que ce qu’on leur fait dire d’habitude. IDC attribue le rapport de 33 à 4 à la maturité de l’organisation : données, processus, infrastructure. RAND incrimine la direction et la communication. Nulle part dans ces travaux on ne lit « personne n’avait le droit d’arrêter ». Cette part relève de notre propre 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 pas de définition commune de l’échec, et qui dérivaient jusqu’à ce qu’un dirigeant perde patience et annule le programme tout entier plutôt que le seul mauvais pari qu’il contenait. Un arrêt défendable coûte moins cher qu’un abandon qui traîne, et le conseil d’administration qui vous a vu arrêter proprement un projet valide le suivant plus vite.

Répondez donc avec soin à la question de l’outillage : elle compte. Mais répondez d’abord à l’autre, par écrit, tant que chacun croit encore au succès du projet : que faudrait-il pour que nous arrêtions ? Si personne ne veut écrire cette phrase, l’outil choisi ne vous sauvera pas.

Dernière relecture : juillet 2026. Ces pages sont relues chaque trimestre ; toute correction est consignée, jamais passée sous silence. Si un chiffre est dépassé, c’est un bogue : écrivez-nous à hello@bearingbridge.com.