L’adoption de l’IA commence souvent par un argumentaire économique simple. Un assistant de code aide les développeurs à travailler plus vite. Un agent prend en charge un travail opérationnel répétitif. Un modèle résume des documents dont l’examen prenait auparavant des heures aux employés.
Un service de décision classe des demandes ou choisit le workflow à exécuter ensuite. Chaque usage peut se justifier en lui-même.
L’équation économique peut aussi être séduisante. Une entreprise peut accomplir davantage avec la même équipe, réduire l’effort répétitif et éviter de développer des capacités qu’un service d’IA peut fournir immédiatement.
Je soutiens cette orientation.
Mais à mesure que l’IA passe de l’aide apportée aux personnes à une place dans le fonctionnement même de l’entreprise, je pense qu’une autre considération mérite autant d’attention :
Quelle part des capacités de l’entreprise appartient encore à l’entreprise ?
Ce n’est pas un plaidoyer contre les fournisseurs d’IA externes. Les entreprises modernes dépendent déjà fortement de plateformes cloud, de produits SaaS, de bases de données, de services de paiement et de bien d’autres technologies externes.
La différence, c’est que l’IA commence à pénétrer des domaines qui relevaient historiquement du jugement humain, du savoir-faire d’ingénierie et de la logique applicative. Cela peut créer une forme de dépendance plus profonde que la simple consommation d’un service technologique de plus.
Le risque apparaît rarement le premier jour. Il se développe progressivement, à mesure que la technologie fait ses preuves.
L’efficacité peut discrètement devenir dépendance
Prenons le développement logiciel. Une entreprise adopte des agents de code parce qu’ils améliorent la productivité. Les développeurs s’en servent pour générer du code, analyser des défaillances, écrire des tests, relire des modifications et comprendre des parties du système qu’ils connaissent mal.
Au début, l’agent est clairement un assistant. La capacité d’ingénierie reste au sein de l’organisation. Mais imaginez la même entreprise plusieurs années plus tard. Les agents réalisent désormais une grande partie du travail d’implémentation courant.
Les équipes rétrécissent. Certains postes juniors disparaissent. La documentation reçoit moins d’attention, puisque l’agent peut inspecter le dépôt au besoin.
Les ingénieurs prennent l’habitude de demander au modèle d’expliquer les systèmes qu’ils connaissent mal, plutôt que de construire eux-mêmes ce savoir. Aucune de ces décisions n’est forcément mauvaise. Prise isolément, chacune peut être rationnelle.
Mais, ensemble, elles soulèvent une question importante :
Si cette capacité d’IA devenait indisponible, beaucoup plus chère ou inadaptée aux besoins de l’entreprise, quelle part du travail l’organisation pourrait-elle encore accomplir seule, en toute confiance ?
C’est là que l’efficacité commence à devenir une question d’architecture.
Alternative textuelle accessible pour cette figure
Cinq étapes, dans l’ordre. Un, assistant d’IA : aide une personne à accomplir son travail. Deux, workflow intégré : l’IA s’intègre à un processus métier reproductible. Trois, capacité opérationnelle : les systèmes et les équipes partent du principe que l’IA est disponible. Quatre, dépendance structurelle : changer la couche d’IA exige une migration, une évaluation ou une adaptation organisationnelle. Cinq, dépendance gérée délibérément : l’organisation conserve les connaissances, l’évaluation, les solutions de repli et la capacité à changer de fournisseur. L’objectif est de gérer la dépendance, pas de s’affranchir de l’IA. Il s’agit d’une analyse de TechiesJournal.
Nous avons déjà vu une facette de ce problème
Dans un précédent point de vue TechiesJournal, Quand l’IA fait le travail des juniors, qui forme la prochaine génération de professionnels ?, j’ai examiné l’effet de l’automatisation du travail grâce auquel on acquérait traditionnellement de l’expérience.
L’inquiétude n’était pas que le travail des juniors doive rester manuel pour toujours. C’était que les organisations devraient comprendre ce qui disparaît d’autre lorsque ce travail disparaît. Les tâches courantes font souvent plus que produire un résultat immédiat.
Elles apprennent aux gens comment les systèmes se comportent. Elles les confrontent aux erreurs. Elles forgent le jugement. Elles forment les ingénieurs, analystes et spécialistes seniors dont une organisation aura besoin plus tard.
La dépendance à l’IA comporte un risque parallèle. Lorsque nous transférons du travail à l’IA, nous pouvons aussi transférer progressivement une partie des connaissances nécessaires pour l’accomplir. Le gain de productivité immédiat est visible. La capacité en train de se perdre est bien plus difficile à voir.
Le sujet dépasse donc la seule question des effectifs. Il devient une question de résilience opérationnelle.
La dépendance s’approfondit quand l’IA entre dans le logiciel
Les agents de code restent relativement faciles à appréhender, car un ingénieur humain demeure visiblement impliqué. L’IA orientée décision change la donne. Traditionnellement, de nombreuses décisions logicielles sont représentées directement dans la logique applicative.
Par exemple :
Une transaction au-delà d’un certain seuil exige un examen supplémentaire. Une demande provenant d’une catégorie de clients suit un workflow donné. Une combinaison particulière de conditions déclenche une action précise. L’entreprise possède ces règles.
Elle peut les inspecter, les tester, les modifier et les exécuter sans demander à un service d’intelligence externe quoi faire. Ce modèle commence à s’élargir.
Jev, de TypeSafe, par exemple, est développé spécifiquement comme un modèle de décision rapide destiné à fonctionner au sein des logiciels. Au lieu de générer de longs textes, il reçoit un état et produit des décisions structurées assorties de probabilités.
OpenAI a également présenté, en préversion limitée, son Decisions API, conçue pour des tâches comme la classification, le routage et le choix de la prochaine action d’une application parmi des possibilités prédéfinies.
Ces technologies sont intéressantes précisément parce qu’elles peuvent rendre les logiciels plus adaptatifs. Mais elles changent aussi la nature de la dépendance.
Si une application demande à un modèle externe :
Quel chemin cette demande doit-elle suivre ?
le modèle n’aide plus seulement un employé. Il fait désormais partie du comportement de l’application. Cela mérite une autre réflexion architecturale.
| Dimension | Logique applicative déterministe | Capacité de décision assistée par l’IA |
|---|---|---|
| Comportement | Des règles explicites définissent le chemin attendu | Un modèle aide à choisir parmi des issues autorisées |
| Propriété | La logique réside principalement dans le code de l’entreprise | L’entreprise possède le workflow, mais une partie du comportement peut dépendre d’un modèle externe |
| Tests | Les règles et les résultats exacts peuvent généralement être vérifiés par assertion | Les évaluations peuvent devoir tester le comportement sur des cas représentatifs |
| Changement de fournisseur | Souvent un remplacement d’implémentation | Peut exiger une comparaison des comportements et une nouvelle validation |
| Repli | Un chemin déterministe connu | Exige un repli ou une escalade conçus intentionnellement |
| Usage le plus adapté | Règles stables aux conditions claires | Situations où l’incertitude ou le jugement apporte une réelle valeur |
Remplacer l’API ne remplace pas forcément la capacité
Il est tentant de penser qu’il suffit, pour régler le problème, de placer le fournisseur derrière une interface. C’est une bonne pratique d’ingénierie, mais cela peut ne pas suffire. Imaginez qu’une organisation utilise un modèle de décision pendant plusieurs années.
Au fil du temps, elle construit :
- des prompts ou des définitions de décision
- des jeux de données d’évaluation
- des seuils de confiance
- des règles d’escalade
- une supervision
- une gestion des exceptions
- des processus métier fondés sur le comportement du modèle.
Puis un autre fournisseur devient plus attractif. L’intégration de l’API peut être facile à remplacer. Le comportement, peut-être pas. Le nouveau modèle peut classer différemment les cas limites.
Les scores de confiance peuvent se comporter différemment. Les seuils peuvent devoir être recalibrés. Les utilisateurs métier peuvent devoir valider les nouveaux résultats. Les workflows réglementés peuvent exiger une nouvelle approbation.
Changer de fournisseur peut alors ressembler moins au remplacement d’une bibliothèque logicielle qu’à la modification d’une partie du système de décision. La dépendance ne tient donc pas forcément à l’API. Elle tient à tout ce que l’organisation a construit autour du comportement de cette IA.
Le prix n’est qu’une des façons dont la dépendance peut se manifester
Il serait trop simpliste de supposer que les fournisseurs d’IA augmenteront sans cesse leurs prix une fois que les entreprises dépendront d’eux. Rien ne permet d’affirmer cela de manière générale, et la concurrence peut faire baisser les prix autant que les faire monter.
Le point le plus important est que le prix unitaire et la dépendance totale sont deux choses différentes.
Un modèle peut devenir moins cher alors que l’entreprise dépense davantage au total.
Pourquoi ?
Parce qu’elle se met à utiliser l’IA à davantage d’endroits. Un développeur utilise un agent pour chaque tâche de code. Le support client devient assisté par des agents. La recherche interne utilise des modèles.
L’analyse de sécurité utilise des modèles. Les workflows métier commencent à appeler des services de décision. Une interaction avec l’IA devient des milliers ou des millions d’interactions automatisées.
TypeSafe le dit explicitement en expliquant le nom Jev : une plus grande efficacité peut libérer une demande bien plus forte d’intelligence machine. C’est commercialement positif lorsque l’usage supplémentaire crée de la valeur.
Mais cela signifie que les organisations ne devraient pas fonder l’économie de leur IA sur le seul prix actuel du jeton. La question la plus importante est de savoir quelle part de l’activité finira par dépendre de l’achat continu d’intelligence externe.
Concevoir la dépendance délibérément
C’est une réflexion d’architecture familière. Les architectes d’entreprise gèrent la dépendance depuis des décennies grâce à la portabilité, à l’abstraction des services, à la reprise après sinistre, à la propriété des données, aux standards ouverts et à la planification de la sortie. L’IA mérite la même discipline.
Mais un élément supplémentaire compte, parce que l’IA peut remplacer des connaissances autant que des technologies. Si une entreprise déplace une base de données d’un cloud à un autre, ses ingénieurs comprennent toujours les bases de données.
Si elle change de plateforme SaaS de paie, son équipe RH comprend toujours la paie.
Mais si l’organisation cesse progressivement de développer une capacité parce qu’un système d’IA s’en charge, l’entreprise peut finir par perdre une partie de l’expertise nécessaire pour remplacer ce système.
La dépendance technologique et la dépendance en capacités peuvent se développer ensemble.
Cela ne signifie pas que les entreprises devraient tout construire elles-mêmes. La plupart des organisations ne devraient ni construire de modèles de pointe ni reproduire des produits que des éditeurs spécialisés peuvent fournir bien plus efficacement.
L’objectif est plus simple :
Utiliser une intelligence externe sans céder inutilement le contrôle de la capacité qui l’entoure.
Cela suppose de garder plusieurs éléments sous le contrôle de l’organisation.
Alternative textuelle accessible pour cette figure
Six éléments qu’une organisation devrait garder sous son contrôle. Un, le contexte métier : données, politiques, terminologie et connaissance du domaine. Deux, l’évaluation : savoir ce qu’est un bon résultat, quel que soit le modèle. Trois, les limites de décision : garder des règles déterministes là où elles suffisent. Quatre, le comportement de repli : définir ce qui se passe lorsque l’IA est indisponible ou incertaine. Cinq, l’expertise interne : comprendre le travail assez bien pour évaluer l’IA. Six, le découplage vis-à-vis du fournisseur : éviter de disséminer partout des hypothèses propres au fournisseur. Le principe central est d’utiliser une intelligence externe sans céder inutilement le contrôle de la capacité qui l’entoure. Il s’agit d’une analyse de TechiesJournal.
Contexte métier
Les données, les politiques, la terminologie et la connaissance du domaine de l’entreprise ne devraient pas exister uniquement au sein d’une implémentation propre à un fournisseur.
Évaluation
L’organisation devrait savoir ce qu’est un résultat « bon », indépendamment du modèle utilisé à un moment donné. Si un autre modèle est introduit, l’entreprise devrait pouvoir le tester au regard de ses propres attentes.
Limites de décision
Là où des règles déterministes suffisent, elles devraient rester déterministes. L’IA devrait être utilisée là où le jugement ou l’incertitude apporte une réelle valeur, plutôt que pour remplacer une logique métier simple au seul motif qu’elle le peut.
Comportement de repli
Les workflows importants devraient définir ce qui se passe si le service d’IA est indisponible, incertain ou hors de ses conditions d’exploitation approuvées.
Expertise interne
Les employés devraient toujours comprendre la capacité métier et technique assez bien pour évaluer ce que fait l’IA.
Découplage vis-à-vis du fournisseur
L’architecture applicative devrait éviter de disséminer inutilement partout des hypothèses propres au fournisseur. Aucune de ces mesures ne supprime la dépendance. Elles rendent la dépendance gérable.
La planification de la sortie devrait commencer avant que la sortie ne soit nécessaire
Cela peut sembler prématuré quand une implémentation d’IA fonctionne bien. C’est justement à ce moment-là que c’est le plus facile. Gartner a récemment formulé une idée voisine en évoquant l’ingénierie déployée sur site par les fournisseurs (forward-deployed engineering) pour l’IA agentique.
Sa crainte est que les organisations puissent progresser rapidement au départ sans pour autant développer assez de capacités internes pour maintenir et faire évoluer de manière autonome le système qui en résulte.
Sa recommandation inclut le transfert de connaissances, la propriété et une stratégie de sortie dès le départ, plutôt que d’attendre que la relation devienne difficile à modifier. Je pense que ce principe s’applique au-delà de l’ingénierie déployée sur site.
Avant qu’une organisation n’intègre un service d’IA externe à une capacité critique, elle devrait comprendre :
- Que devrions-nous changer si ce service était indisponible ?
- De quelles connaissances aurions-nous besoin en interne ?
- Qu’est-ce qui nécessiterait une nouvelle validation ?
- Quelles données et quelles évaluations contrôlons-nous ?
- Un autre modèle pourrait-il remplir ce rôle ?
- Qu’est-ce qui resterait opérationnel pendant que nous le changerions ?
Ces questions ne se posent pas parce que nous nous attendons à une défaillance du fournisseur. Elles se posent parce qu’une architecture responsable part du principe que la technologie change.
Le coût devrait se mesurer au-delà de la consommation
Cela change aussi ma façon d’envisager le FinOps de l’IA. Les jetons, les appels de modèle, le temps d’exécution des agents et l’usage des outils comptent toujours. Mais le tableau économique est plus large.
Une organisation mature pourrait finir par avoir besoin de comprendre :
Coût d’exploitation
Combien coûte ce workflow d’IA aujourd’hui ?
Valeur
Quel travail ou quel résultat métier cette dépense produit-elle ?
Coût de changement
Combien coûterait le transfert de cette capacité ailleurs ?
Coût en capacités
Quelles compétences internes s’affaiblissent parce que l’IA fait le travail ? Ces deux derniers coûts sont plus difficiles à faire figurer dans un tableau de bord. Ils pourraient pourtant compter davantage sur le long terme qu’une petite différence de prix des jetons.
Point de vue
La première étape de l’adoption de l’IA en entreprise portait surtout sur les capacités. Le modèle peut-il écrire du code utile ? Peut-il comprendre des documents ? L’agent peut-il mener la tâche à bien ?
Le modèle de décision peut-il améliorer le workflow ?
L’étape suivante exige une autre considération :
Qu’advient-il de l’organisation à mesure que ces systèmes s’intègrent au travail quotidien ?
Un système d’IA qui réussit sera naturellement de plus en plus utilisé. Les équipes concevront des processus autour de lui. Les employés apprendront à s’appuyer sur lui. Les logiciels commenceront à compter sur sa disponibilité.
Ce n’est pas un échec. C’est à cela que ressemble une adoption technologique réussie. Mais le succès crée de la dépendance.
La responsabilité de l’architecture n’est pas d’éliminer cette dépendance. Elle consiste à s’assurer que l’organisation la comprend et conserve assez de contrôle pour s’adapter lorsque la technologie, l’économie ou les besoins métier changent.
Pour moi, le principe est simple :
Utilisez l’IA là où elle crée de la valeur. Laissez-la supprimer le travail inutile. Laissez-la améliorer les décisions. Mais conservez les connaissances, l’évaluation, l’architecture et le contrôle opérationnel nécessaires pour changer la manière dont cette intelligence est fournie.
La distinction importante ne sépare pas les entreprises qui dépendent de l’IA de celles qui n’en dépendent pas. La plupart des organisations sérieuses en dépendront probablement. La distinction se fera entre une dépendance apparue par accident et une dépendance conçue délibérément.
Pour aller plus loin : Construire des systèmes agentiques : de votre premier agent à un système fiable traite des limites et de la fiabilité à mesure que l’autonomie des agents augmente, et Jev expliqué : pourquoi ce modèle d’IA prend des décisions au lieu de rédiger des réponses (en anglais) présente le modèle de décision évoqué plus haut.
Sources et lectures complémentaires
Sources vérifiées le 5 octobre 2026.
- TypeSafe AI — Introducing System One Models & Jev. Présentation par TypeSafe de son modèle de décision en accès anticipé et des raisons de concevoir une IA spécifiquement pour les décisions logicielles structurées. Publié le 15 septembre 2026. Les chiffres de performance de la source sont communiqués par le fournisseur.
- OpenAI — DevDay 2026 Recap: Decisions API. Description par OpenAI de Decisions API pour la classification, le routage et la sélection d’actions parmi des choix prédéfinis, en préversion limitée au 29 septembre 2026. La disponibilité a pu évoluer depuis.
- Gartner — Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028. Analyse de Gartner sur l’ingénierie d’IA déployée sur site, qui met l’accent sur le transfert de connaissances, la propriété, les capacités internes et la planification de la sortie. La prévision concerne l’ingénierie déployée sur site par les fournisseurs, pas l’ensemble de l’IA d’entreprise.
- TechiesJournal — Quand l’IA fait le travail des débutants, qui forme la prochaine génération de professionnels ?. Précédent point de vue d’auteur sur ce que les organisations risquent de perdre lorsque l’IA automatise un travail qui développait auparavant les capacités professionnelles de demain.
- TechiesJournal — Construire des systèmes agentiques : de votre premier agent à un système fiable. Analyse pratique des limites, de la fiabilité et des considérations d’exploitation à mesure que l’autonomie des agents augmente.