Presque toutes les entreprises louent aujourd'hui leur intelligence artificielle. Elles souscrivent un abonnement, connectent quelques outils, et constatent un gain réel de productivité. C'est une bonne décision. Ce n'en est pas une stratégique, et la confusion entre les deux explique une grande partie des déceptions que nous observons au bout de dix-huit mois.
L'IA sur étagère produit de la parité, pas de l'avantage
Un outil que tout le monde peut acheter élève le plancher de tout un secteur. Il ne creuse aucun écart. Si votre concurrent peut souscrire demain le même abonnement, utiliser le même modèle avec les mêmes instructions et obtenir le même résultat, alors ce que vous avez acheté est un coût d'exercice du métier, pas un différenciateur.
Le mécanisme n'a rien de nouveau. Les progiciels de gestion intégrés dans les années 1990, puis les sites web dans les années 2000, ont suivi exactement la même trajectoire : indispensables, et parfaitement indifférenciants une fois généralisés. L'entreprise qui n'en avait pas était pénalisée, celle qui en avait un n'était pas pour autant avantagée.
Ce constat n'est pas un argument contre l'achat d'outils. C'est un argument contre le fait de confondre l'équipement et la stratégie.
Ce que la théorie des ressources dit de l'IA
L'approche par les ressources, formalisée par Jay Barney en 1991 et souvent résumée par l'acronyme VRIO, propose un test simple. Une ressource ne produit un avantage concurrentiel durable que si elle est de valeur, rare, difficile à imiter, et si l'organisation est capable de l'exploiter.
Passons le modèle de langage à ce test. De valeur, incontestablement. Rare, absolument pas : n'importe qui y accède en trois minutes avec une carte bancaire. Difficile à imiter, encore moins : l'imitation se fait en un clic. Le modèle échoue donc structurellement à deux des quatre critères. Il est incapable, à lui seul, de produire un avantage durable, quelle que soit sa qualité.
Ce résultat est important parce qu'il déplace la question. Si le modèle est un bien de marché, alors l'avantage se loge ailleurs : dans ce qui l'entoure et que personne ne peut acheter.
Où se loge réellement l'avantage
- Vos corpus qualifiés : documents nettoyés, structurés et rattachés à votre réalité métier, ce qui prend des mois et ne se télécharge nulle part
- Vos règles métier explicitées : instructions system, skills, critères d'arbitrage, seuils de validation, exceptions documentées
- Vos jeux d'évaluation : quelques dizaines de cas réels avec la réponse attendue, qui transforment votre exigence de qualité en mesure
- Votre tuyauterie : connecteurs, intégrations aux logiciels métiers, gestion fine des droits
- Votre savoir d'exploitation : ce qui casse, ce qu'il faut surveiller, comment revenir en arrière
- Vos boucles de retour : les corrections des utilisateurs captées et réinjectées dans le système
Aucun de ces six actifs ne s'achète. Tous s'accumulent. Et tous restent valables lorsque le modèle change, ce qui arrive environ deux fois par an. C'est exactement la définition d'une ressource rare et difficile à imiter.
Se décorréler des acteurs extérieurs, sans fantasmer l'indépendance
Il faut être précis ici, car le discours ambiant sur la souveraineté verse vite dans la promesse creuse. Personne n'est indépendant. Une architecture open weights installée dans vos murs dépend encore d'un fabricant de GPU, d'une chaîne d'approvisionnement, d'un réseau électrique, souvent d'un hébergeur, et de bibliothèques logicielles maintenues par des tiers. Annoncer une indépendance vis-à-vis des fournisseurs serait un abus de langage.
L'objectif atteignable, et bien plus utile, tient en trois qualités : un système résilient, gouverné et réversible. La résilience absorbe les chocs, la gouvernance rend le système lisible et contrôlable, la réversibilité borne le coût de sortie. Ce triptyque se mesure, contrairement à l'indépendance qui ne se mesure pas.
Ce que cela veut dire concrètement
- Garder prompts, règles et jeux d'évaluation dans vos dépôts, sous un format portable, et non enfermés dans l'interface d'un éditeur
- Placer une couche d'abstraction entre vos applications et le modèle, pour qu'un changement de fournisseur soit un paramètre et non un chantier
- Savoir précisément quelles données sortent de votre périmètre, vers où, et sous quel droit
- Documenter la sortie avant de signer l'entrée : format d'export, propriété des données produites, délai de récupération
- Prévoir un mode dégradé qui permet de continuer à travailler si le service principal tombe
- Tester un changement de modèle une fois par an, sur vos jeux d'évaluation, et chronométrer l'opération
Ce dernier point est le plus révélateur, et c'est celui que nous proposons en premier lors d'un cadrage. Un test de sortie ne coûte que quelques jours et il produit un chiffre : le temps nécessaire pour reprendre l'activité si votre fournisseur principal disparaissait. Tant que ce chiffre est inconnu, la dépendance est subie plutôt que choisie.
La durabilité vient de l'accumulation
C'est le point qui distingue une dépense d'un investissement. Chaque mois d'exploitation approfondit vos actifs, à condition que vous les captiez. Les corrections des utilisateurs enrichissent vos jeux d'évaluation. Les cas limites rencontrés en production deviennent des règles écrites. Le vocabulaire métier se stabilise. Au bout de deux ans, ce patrimoine est difficile à répliquer, y compris par un concurrent mieux financé.
À l'inverse, une entreprise qui loue l'intégralité de sa chaîne ne capitalise rien. Au bout de trois ans, elle possède trois ans de factures, un gain de productivité réel mais partagé avec tout son secteur, et une capacité de négociation nulle le jour où les conditions changent.
“Le modèle est un bien de marché. Le contexte que vous lui donnez est un actif. Le premier se remplace en une journée, le second se construit en deux ans.”
Ce que cela implique pour vos projets
Cela ne signifie pas qu'il faut tout internaliser, ni refuser les services du marché. Cela signifie que chaque projet doit être évalué à l'aune d'une question supplémentaire : que reste-t-il à l'entreprise quand le projet est terminé ? Un projet qui laisse un corpus qualifié, des règles écrites et un jeu d'évaluation vaut structurellement plus qu'un projet équivalent qui laisse un abonnement de plus.
C'est la raison pour laquelle notre méthode commence par l'écoute et se termine par un transfert. L'objectif d'une mission n'est pas de vous rendre dépendant d'un prestataire de plus, mais de vous laisser propriétaire d'un actif que vous saurez faire vivre.