Cette année, l’IA ne se vend plus de la même façon. L’unité de vente n’est plus le développement sur mesure mais la plateforme assemblée : un environnement d’exécution pour les agents, une couche de gouvernance, une place de marché de composants prêts à l’emploi, et des équipes pour raccorder l’ensemble à ce que vous exploitez déjà. Les prestataires se présentent avec un logiciel déjà écrit, et plus seulement avec des ingénieurs qui en écriront pour vous.
Nous prenons le même virage, et à raison selon nous. Orchestration, journalisation, contrôle d’accès, gestion du cycle de vie : ce sont des problèmes résolus, transposables d’un client à l’autre, et les reconstruire à chaque mission a toujours été du gaspillage. C’est précisément pour cela qu’existe notre propre couche d’intelligence, bearingbridge intelligence. Elle ingère données, contenus et documents de multiples sources, afin que le travail ne reparte pas de zéro à chaque mission.
L’autre moitié, en revanche, aucun d’entre nous n’a trouvé le moyen d’en faire un produit. La question à trancher avant d’acheter est donc plus étroite que le discours commercial : que peut-on acheter, et que garderez-vous à votre charge, quel que soit le prestataire choisi ?
Ce qui est à vendre, et ce qui ne l’est pas
| Fourni avec la plateforme | Reste de votre ressort |
|---|---|
| Exécution et orchestration des agents | L’état de vos données sources |
| Journalisation, contrôle d’accès, observabilité | Vos règles réelles sont-elles écrites ? |
| Composants prêts à l’emploi pour les fonctions courantes | Qui assume une réponse erronée |
| Infrastructure multicloud et multimodèle | Le seuil d’arrêt |
| Modèles de déploiement pour les environnements réglementés | Le chiffre que vous affirmez avoir fait bouger |
Aucune signature ne fait changer un élément de colonne.
La colonne de gauche relève de l’ingénierie véritable, et l’acheter est en général le bon choix. C’est dans celle de droite que les programmes d’IA échouent réellement. Aucune décision d’achat ne fait passer un seul élément de droite à gauche.
La promesse qui déplace le risque
L’argument en vogue est aujourd’hui une couche sémantique gouvernée, déployée sur vos bases de données, vos référentiels documentaires et vos flux d’événements, sans programme de consolidation préalable. Les agents obtiennent une vue structurée de l’entreprise sans passer d’abord par dix-huit mois de migration.
La promesse séduit, et elle est techniquement honnête. Quiconque a vu un programme de consolidation des données s’éteindre au neuvième mois comprend pourquoi elle se vend.
Le risque, lui, se déplace sans disparaître. Posée sur des données incohérentes, une vue gouvernée produit des réponses incohérentes, plus vite, et les consigne toutes. Si un même client apparaît dans trois systèmes sous deux orthographes, le graphe de connaissances en hérite sans rien résoudre. Si votre nomenclature produits a changé en 2023 et que la moitié des documents suit encore l’ancienne, l’agent lit les deux et les tient pour aussi actuelles l’une que l’autre. La gouvernance vous dit ce que l’agent a lu. Elle ne vous dit pas quelle version était la bonne.
La gouvernance vous dit ce que l’agent a lu. Elle ne vous dit pas quelle version était la bonne.
D’où notre principe maison : le contexte fait tout, et le contexte vient des données. Il est né d’un pilote mené pour un acteur des produits de grande consommation : les résultats étaient décevants et le client mettait en cause le modèle. À tort. La documentation de référence était maigre, périmée par endroits, contradictoire ailleurs. Changer de modèle n’a rien changé de mesurable. Corriger les sources a changé le résultat.
Une plateforme assemblée ne dispense personne de ce travail, pas même la nôtre. Elle change seulement le moment où l’on découvre qu’il fallait le faire, et le découvrir après le déploiement coûte plus cher.
Quatre sortes de chiffres
Les argumentaires des plateformes regorgent de chiffres, et quatre espèces différentes y sont présentées avec la même assurance. Entre le communiqué et la quatrième diapositive, « devrait permettre » devient « permet ». Personne ne le décide. Cela se glisse quelque part dans la présentation, et le temps que quelqu’un s’en aperçoive, le chiffre est inscrit au budget.
Le registre des affirmations. Ouvrez une ligne pour voir ce qu’elle prouve et ce qu’il faut exiger. Bilan : 1/4 tranche la question.
| Affirmation | Verdict | Ce qu’elle prouve | Ce qu’il faut exiger |
|---|---|---|---|
| Un nombre de déploiements | Livré, quelque part | Il a été livré quelque part | À qui, pour quel usage, sur quelle durée |
| Un gain de vitesse déclaré | Une impression | Une impression, non auditée | Point de départ, méthode, auteur de la mesure |
| Une économie projetée | Un modèle | Un modèle de l’avenir, pas un résultat | Les hypothèses, et qui en répond |
| Un résultat mesuré | Tranche la question | La seule catégorie qui permette de trancher | Un avant et un après, tous deux datés |
Tranche la question : un résultat mesuré. Appellent une seconde question : un nombre de déploiements, un gain de vitesse déclaré, une économie projetée.
La deuxième ligne appelle une méfiance particulière : cette catégorie-là a été testée dans les règles.
Lors d’un essai contrôlé randomisé, des développeurs expérimentés autorisés à utiliser des outils d’IA ont mis 19 % de temps en plus pour mener à bien des tâches réelles, tout en estimant après coup que ces outils les avaient rendus 20 % plus rapides.
METR, juillet 2025 · 16 développeurs, 246 tâches
Les mêmes développeurs, sur les mêmes tâches :
- Ce qu’ils ont estimé : 20 % plus rapides
- Ce qui a été mesuré : 19 % de temps en plus
39 points de pourcentage d’écart, et dans le sens qui les flattait.
METR a depuis reconduit l’essai sur des outils plus récents et signalé sur sa propre page que l’original était dépassé, un détail qui a échappé à la plupart de ceux qui le citent.
Chez les développeurs de l’étude initiale qui ont participé à nouveau, le gain estimé atteignait 18 %. Chez les nouveaux venus, 4 %.
METR, février 2026, sur des outils de fin 2025. Le chiffre de 2025 cité plus haut est signalé comme dépassé par ses propres auteurs.
Mettez de côté les chiffres qui font les titres. Reste ceci : les participants au premier essai se sont trompés de 39 points de pourcentage sur leur propre productivité, dans le sens qui les flattait. Il s’agissait de professionnels chevronnés, qui travaillaient sur un code qu’ils connaissaient bien. Votre équipe n’y échappe pas, et nous non plus.
C’est pourquoi un chiffre de productivité avancé par un éditeur, le nôtre compris, ne peut pas porter le poids que les acheteurs lui prêtent. La version qui trancherait est d’une autre nature : une mesure initiale prise avant, la même mesure reprise après, selon la même méthode, les deux dates consignées.
La souveraineté, une propriété et non un slogan
Voilà pour l’achat. Reste l’autre moitié de la discussion : où tout cela a le droit de résider.
Toutes les plateformes du secteur mettent désormais en avant le contrôle : vos données, vos modèles, vos décisions, gardés là où vous l’entendez. Pour un acheteur européen, c’est bien par là qu’il faut commencer. Mais la souveraineté se teste, et quatre questions y parviennent plus vite que n’importe quel schéma d’architecture.
L’emplacement
Commencez par savoir où se trouve physiquement la couche de contexte, et sous quelle juridiction. Pas les modèles : le contexte lui-même, c’est-à-dire le graphe de connaissances, les embeddings, toute la logique tirée de vos procédures. Cet ensemble constitue une description condensée du fonctionnement de votre entreprise, et il vaut plus que n’importe lequel des documents qui l’ont nourri.
Les lecteurs
Ensuite, qui peut le consulter. Le support de l’éditeur pendant un incident est une réponse normale. Le problème commence seulement quand personne n’a posé la question.
Le transfert
Demandez ensuite ce qui quitte l’entreprise au moment de l’inférence. Un prompt qui transporte des fiches clients vers un modèle hébergé est un transfert de données, quel que soit le nom que lui donne le schéma.
La sortie
Que se passe-t-il si vous partez la troisième année ? Exporter la définition d’un flux de travail est facile. Exporter la couche de contexte, les réglages et tout le savoir accumulé sur le comportement de vos agents est une tout autre affaire. L’absence de dépendance au fournisseur est une promesse à vérifier, pas une caractéristique à accepter telle quelle, et c’est avant la signature qu’il faut la vérifier, tant que vous gardez la main dans la négociation.
Ce que nous ferions d’abord
Rien de tout cela ne plaide contre l’achat de la plateforme. C’est une affaire de séquence. Quatre chantiers, avant que la décision ne soit prise.
Auditez le contexte, pas le modèle.
Prenez les vingt documents et les trois systèmes qu’un premier agent lirait vraiment. Vérifiez qu’ils sont à jour, qu’ils ne se contredisent pas, et comptez les quasi-doublons. Commencez par trier selon la date de dernière modification. Si le document de politique qu’un agent de support citera n’a pas été touché depuis 2021 alors que la règle a changé deux fois entre-temps, vous avez la réponse avant même d’ouvrir un fichier. Comptez quelques jours, pas des trimestres.
Les règles non écrites
Repérez ensuite ce qui n’est consigné nulle part. Extraire la logique des procédures opérationnelles fonctionne bien quand celles-ci sont exactes. Mais lorsque la vraie règle n’existe que dans la tête d’un cadre chevronné et que le document se trompe depuis des années, l’extraction encodera fidèlement la mauvaise règle, piste d’audit à l’appui.
Le point de départ
Mesurez le chiffre que vous comptez faire bouger avant le moindre déploiement, avec la même méthode avant et après, dates à l’appui. Faute de quoi, rien ne permet de distinguer une économie réelle d’une projection que plus personne ne discute.
Écrivez le critère d’arrêt.
Un seuil de qualité, un plafond de coût et un test de passation, chacun assorti d’un chiffre et d’une date, arrêtés tant que tout le monde est encore optimiste. C’est le seul moment où l’on écrit ce genre de règle honnêtement.
Aucune de ces quatre étapes ne demande un trimestre. Ensemble, elles représentent deux ou trois semaines de travail, et elles changent ce que vous achetez, non la décision d’acheter.
C’est en sautant cette dernière étape que les programmes viennent grossir le chiffre suivant, qui compte les abandons et non les échecs. La nuance compte : c’est l’abandon qui coûte cher.
La part des entreprises qui renoncent à l’essentiel de leurs initiatives d’IA est passée de 17 % à 42 % en un an ; 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
La progression des entreprises qui renoncent à l’essentiel de leurs initiatives d’IA :
- 17 % : renoncent à l’essentiel de leurs initiatives d’IA
- 42 % : un an plus tard
- 46 % : des preuves de concept abandonnées avant la production, dans l’organisation moyenne
Cette dernière étape, c’est la phase Cap d’AZIMUTH, présentée sur la page Méthode, et c’est celle que les clients contestent le plus âprement. Un arrêt motivé coûte moins cher qu’un abandon qui s’éternise, et l’écart demeure quand le projet arrêté est un programme de plateforme adossé à une place de marché.
Achetez donc la moitié qui peut devenir un produit. C’est en général une ingénierie de meilleure qualité que ce qu’une équipe produirait en interne, et elle coûte moins cher. Mais gardez les yeux ouverts : l’autre moitié, à savoir vos données, vos règles écrites et la personne dont le nom sera associé au résultat, ne figure pas au contrat et n’y a jamais figuré.
