La vente de projets d’IA a changé de nature cette année. L’unité n’est plus le développement sur mesure, mais la plateforme assemblée : un moteur d’agents, une couche de gouvernance, une place de marché de composants prêts à l’emploi, et des équipes pour brancher l’ensemble sur l’existant. Les prestataires arrivent désormais avec du logiciel déjà écrit, et non plus seulement avec des ingénieurs prêts à en écrire.
Nous suivons le même chemin, et nous pensons que c’est le bon. Orchestration, journalisation, contrôle d’accès, gestion du cycle de vie : autant de problèmes résolus, valables d’un client à l’autre, que chaque mission n’a aucune raison de reconstruire. Notre propre couche d’intelligence,bearingbridge intelligence, existe précisément pour cela : elle ingère données, contenus et documents de sources multiples, pour que le travail ne reparte pas de zéro à chaque mission.
Reste l’autre moitié, celle que personne n’a su transformer en produit. La question d’achat est donc plus étroite que l’argumentaire : quelles parties s’achètent réellement, et lesquelles restent chez vous, quel que soit le prestataire retenu.
Ce qui est à vendre, et ce qui ne l’est pas
- Le moteur d’agents et l’orchestration
- La journalisation, le contrôle d’accès, l’observabilité
- Les composants préconstruits pour les fonctions courantes
- La tuyauterie multi-cloud et multi-modèles
- Les schémas de déploiement en environnement réglementé
- L’état de vos données sources
- Vos vraies règles, écrites ou non
- Qui répond d’une réponse fausse
- Le seuil auquel vous arrêtez
- Le chiffre que vous affirmez avoir fait bouger
La colonne de gauche, c’est de l’ingénierie véritable, et l’acheter est le plus souvent la bonne décision. La colonne de droite, c’est là que les programmes d’IA échouent pour de bon. Aucune décision d’achat n’en fait passer un seul élément de droite à gauche.
La promesse qui déplace le risque
Le discours commercial du moment promet une couche sémantique gouvernée, posée sur vos bases de données, vos fonds documentaires et vos flux d’événements, sans exiger d’abord le grand programme de consolidation. Les agents obtiennent une vue structurée de l’entreprise sans dix-huit mois de migration préalable.
La promesse est séduisante, et techniquement honnête. Qui a vu un programme de consolidation de données mourir au neuvième mois comprend pourquoi elle fait vendre.
Mais le risque se déplace, il ne disparaît pas. Une vue gouvernée sur des données incohérentes renvoie des réponses incohérentes plus vite, et les consigne toutes. Si le même client figure dans trois systèmes sous deux orthographes, le graphe de connaissances en hérite ; il ne le résout pas. Si votre nomenclature produit a changé en 2023 et que la moitié des documents s’en tiennent à 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 dira pas quelle version était vraie.
La gouvernance vous dit ce que l’agent a lu. Elle ne vous dira pas quelle version était vraie.
D’où notre ligne maison : le contexte est tout, et le contexte vient des données. Elle est née d’un pilote mené dans les produits de grande consommation : les sorties étaient médiocres, le client incriminait le modèle. À tort. Le référentiel était maigre, périmé par endroits, contradictoire ailleurs. Changer de modèle n’a rien déplacé de mesurable. Corriger la matière première a changé le résultat.
Une plateforme assemblée n’exonère personne de ce travail, nous compris. 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 espèces de chiffres
Les argumentaires de plateforme avancent des chiffres, et quatre espèces bien distinctes y défilent sur le même ton assuré. Quelque part entre l’annonce et la quatrième diapositive, « devrait permettre » devient « permet ». Personne ne le décide. Cela se produit quelque part dans le deck, et le temps qu’on s’en aperçoive, c’est inscrit au budget.
Ouvrez une ligne pour voir ce qu’elle établit, et ce qu’il reste à demander.
Un nombre de déploiementsLivré, quelque part
Que le produit a été livré quelque part
À qui, pour faire quoi, sur quelle durée
Un gain autodéclaréUne impression
Une impression, jamais auditée
La mesure de départ, la méthode, l’auteur de la mesure
Une économie projetéeUn modèle
Un modèle de l’avenir, pas un résultat
Les hypothèses, et qui les signe
Un résultat mesuréTranche
La seule espèce qui tranche quoi que ce soit
Un avant et un après, tous deux datés
La deuxième ligne mérite une méfiance particulière, parce que cette espèce-là, quelqu’un l’a testée sérieusement.
Dans un essai randomisé contrôlé, des développeurs expérimentés ont mis 19 % de temps de plus à terminer des tâches réelles lorsqu’ils pouvaient recourir à des outils d’IA, tout en estimant ensuite que ces outils les avaient rendus 20 % plus rapides.
39 points d’écart, dans le sens qui les arrangeait.
METR a depuis refait l’essai sur des outils plus récents et signale, sur sa propre page, que le résultat initial est périmé. Peu de ceux qui le citent l’ont remarqué.
Chez les développeurs de la première étude qui ont repris part à l’exercice, le gain estimé était de 18 %. Chez les nouveaux venus, de 4 %.
Laissez les gros titres de côté. Ce qui demeure, c’est que les participants du premier essai se trompaient de 39 points sur leur propre productivité, dans le sens qui les arrangeait. Des professionnels aguerris, dans un code qu’ils connaissaient bien. Votre équipe n’y échappe pas. La nôtre non plus.
C’est pourquoi un chiffre de productivité avancé par un fournisseur, le nôtre compris, ne peut pas porter le poids que les acheteurs lui prêtent. La version qui trancherait a une autre allure : une mesure prise avant, la même répétée après, méthode identique, dates consignées.
La souveraineté est une propriété, pas un slogan
Voilà pour l’achat. L’autre moitié de la conversation porte sur l’endroit où tout cela a le droit de résider.
Toutes les plateformes de la catégorie mettent désormais le contrôle en avant : vos données, vos modèles, vos décisions, à l’endroit de votre choix. Face à un acheteur européen, c’est le bon angle. Mais la souveraineté se teste, et quatre questions y suffisent, plus vite que n’importe quel schéma d’architecture.
Commencez par le lieu physique où réside la couche de contexte, et sous quelle juridiction. Pas les modèles. Le contexte lui-même : le graphe de connaissances, les embeddings, toute la logique extraite de vos procédures. Cet artefact est une description compressée du fonctionnement de votre entreprise, et il vaut plus que n’importe lequel des documents qui l’ont alimenté.
Ensuite, qui peut le lire. Le support du fournisseur pendant un incident est une réponse normale. Elle ne devient un problème que si personne n’a posé la question.
Demandez ensuite ce qui sort de l’entreprise au moment de l’inférence. Un prompt qui emporte des données clients vers un modèle hébergé est un transfert de données, quel que soit le nom que lui donne le schéma.
Que se passe-t-il si vous partez la troisième année ? Exporter une définition de workflow est simple. Exporter la couche de contexte, les réglages et le savoir accumulé sur le comportement de vos agents l’est beaucoup moins. « Aucun verrouillage » est une affirmation à vérifier, pas une caractéristique à accepter, et elle se vérifie avant signature, tant que le rapport de force est de votre côté.
Ce que nous ferions passer en premier
Rien de tout cela ne plaide contre l’achat de la plateforme. C’est une question d’ordre des opérations. Quatre chantiers, avant que la décision ne se prenne.
Auditez le contexte, pas le modèle.
Prenez les vingt documents et les trois systèmes qu’un premier agent lira réellement. Vérifiez s’ils sont à jour, s’ils se contredisent, combien de quasi-doublons circulent. Triez d’abord par date de dernière modification. Quand la politique que citera un agent de support n’a pas bougé depuis 2021 alors que la vraie a changé deux fois depuis, la réponse est acquise avant d’avoir ouvert le moindre fichier. C’est un travail de quelques jours, pas de trimestres.
Cherchez ensuite ce qui n’est écrit nulle part. Extraire la logique des procédures opérationnelles fonctionne bien là où elles sont exactes. Là où la vraie règle vit dans la tête d’une seule personne expérimentée et où le document est faux depuis des années, l’extraction encodera fidèlement la mauvaise règle, piste d’audit à l’appui.
Mesurez, avant tout déploiement, le chiffre que vous comptez faire bouger, avec la même méthode les deux fois et les deux dates consignées. Sans cela, impossible de distinguer une économie réelle d’une projection que plus personne n’interroge.
Écrivez le critère d’arrêt.
Un plancher de qualité, un plafond de coût, un test de passage de relais, chacun avec un chiffre et une date, actés pendant que l’optimisme est encore général. C’est le seul moment où pareille chose s’écrit honnêtement.
Aucun des quatre ne demande un trimestre. Ensemble, c’est une quinzaine de jours de travail, et ils changent ce que vous achetez, pas la décision d’acheter.
Sauter le dernier, c’est ainsi que les programmes finissent dans le chiffre qui suit, lequel compte les abandons, pas les échecs. Les deux ne se confondent pas, et l’abandon est le plus cher des deux.
La part des entreprises abandonnant l’essentiel de leurs initiatives d’IA est passée de 17 % à 42 % en un an, l’organisation moyenne renonçant à 46 % de ses preuves de concept avant la production.
Ce dernier chantier, c’est la phase Bearing d’AZIMUTH, décrite sur lapage Méthode, et c’est celle où nos clients résistent le plus. Un arrêt défendable coûte moins cher qu’un abandon au ralenti, et l’écart se creuse encore quand ce qu’on arrête est un programme de plateforme, place de marché comprise.
Achetez donc la moitié qui se transforme en produit. C’est en général une meilleure ingénierie que ce qu’une équipe produirait en interne, et pour moins cher. Gardez simplement les yeux ouverts : l’autre moitié, vos données, vos règles écrites, la personne dont le nom porte le résultat, ne figure pas au contrat. Elle n’y a jamais figuré.