IA générative : de l'adoption à la capacité propriétaire

L’adoption de l’IA générative est une première étape. Elle ne constitue pas, à elle seule, une stratégie de transformation. Former les collaborateurs développe les usages, révèle des opportunités et peut améliorer la productivité. Mais si l’entreprise ne sait pas transformer ces apprentissages en capacités réutilisables, elle risque surtout d’accroître sa dépendance à des fournisseurs externes.

Le problème n’est pas de payer un modèle ou une plateforme SaaS. Le problème est de réapprendre et de repayer indéfiniment ce que l’organisation aurait pu transformer en savoir-faire exécutable, gouverné et propriétaire.

Former les collaborateurs à l’IA crée de l’usage. Déployer des agents crée de l’automatisation. Construire une software factory agentique crée les conditions pour produire et faire évoluer des actifs logiciels propriétaires.

Cette distinction doit devenir une priorité des comités exécutifs : elle touche à la marge, à la cybersécurité, à l’autonomie stratégique, aux compétences et, finalement, à la valeur de l’entreprise.

1. L’adoption ouvre des perspectives ; elle ne garantit pas la captation de valeur

Les solutions spécialisées dans l’adoption, telles que Mendo, répondent à un besoin concret : aider les équipes à apprendre et à utiliser l’IA dans leur travail. Les plateformes d’agents, telles que Dust, facilitent pour leur part l’accès aux données et aux outils, l’orchestration d’assistants et certains contrôles d’usage.

Ce sont des étapes utiles. Mais adoption, automatisation et maîtrise ne sont pas synonymes.

Un collaborateur apprend à produire un rapport avec un LLM : la tâche devient plus rapide. Une équipe crée un agent qui répète cette opération : une partie du travail est automatisée. Toutefois, si les critères de décision, les contrôles qualité, les intégrations, les preuves d’exécution et les règles métier restent enfermés dans une plateforme, l’organisation n’a pas nécessairement créé de capacité transférable.

Elle a créé de l’usage. Une partie de la valeur peut être captée par le fournisseur sous forme d’abonnements, de consommation d’inférence, de dépendance aux connecteurs et d’intégration croissante dans les processus.

J’appelle fuite de valeur IA (AI value leakage) ce risque de financer l’apprentissage et l’automatisation sans en capitaliser les résultats. C’est une grille d’analyse stratégique, non un indicateur comptable standard.

La question à poser n’est donc plus seulement : « Combien de personnes utilisent l’IA ? » Elle devient : « Quelle part de ce que nous apprenons grâce à l’IA devient une capacité que nous possédons, maîtrisons et pouvons réutiliser ? »

2. Après le SaaS sprawl, le risque d’AI sprawl

Les grands groupes connaissent la fragmentation du système d’information : multiplication des solutions SaaS, doublons fonctionnels, abonnements sous-utilisés, intégrations fragiles, données réparties entre fournisseurs et gouvernance mise en place trop tard.

L’IA peut reproduire ce phénomène, avec une portée nouvelle. Chaque département peut créer ses agents, ses prompts, ses connecteurs et ses workflows. Deux équipes finissent par automatiser le même processus avec deux plateformes différentes. Personne ne sait précisément quelle version de l’agent a produit une décision, quels droits lui étaient accordés ni comment reproduire son résultat.

Le SaaS sprawl fragmentait les applications. L’AI sprawl peut fragmenter les capacités opérationnelles et décisionnelles.

On ne parle plus seulement d’un catalogue logiciel dispersé. On parle de règles métier implicites, de décisions assistées, de mémoire opérationnelle, de connaissances organisationnelles et de permissions d’exécution réparties dans des environnements hétérogènes.

Sans inventaire, sans standards ni architecture cible, l’entreprise risque de constituer une dette agentique : des automatisations faciles à créer, mais difficiles à maintenir, à auditer, à sécuriser ou à remplacer.

La rationalisation ne peut donc pas attendre. Il faut inventorier les modèles, les plateformes, les agents, leurs propriétaires, les accès, les flux de données, les dépendances et les coûts — mais aussi les capacités métier qu’ils réalisent et les preuves qu’ils produisent.

3. Une plateforme d’agents peut déplacer la dépendance sans la supprimer

Passer d’un accès direct à un fournisseur de LLM à une plateforme d’agents SaaS peut apporter une réelle simplification. Cela peut aussi introduire une nouvelle couche de dépendance :

Entreprise
  → plateforme agentique SaaS
    → modèles, outils et services sous-jacents

Les risques précis varient selon les contrats, les architectures et les capacités d’export offertes. Il serait faux de prétendre que toute plateforme SaaS prive nécessairement ses clients de leurs données ou de leurs droits sur les contenus. En revanche, l’entreprise doit vérifier sa portabilité effective.

Peut-elle exporter ses workflows ? Rejouer ses tests hors plateforme ? Conserver son registre de décisions et ses preuves ? Remplacer le modèle ? Porter un agent vers un autre runtime ? Récupérer ses politiques et ses contrats d’outils ?

La souveraineté opérationnelle ne consiste pas à tout héberger. Elle consiste à pouvoir substituer les briques sans perdre ce qui crée la valeur.

4. L’erreur inverse : croire que posséder des GPU revient à posséder sa capacité

Certaines entreprises reconnaissent cette dépendance puis répondent par un investissement massif en serveurs GPU ou en plateformes d’inférence privées.

Une infrastructure dédiée peut être judicieuse lorsque les volumes, la confidentialité, les compétences et l’économie des charges de travail le justifient. Elle peut aussi devenir une dette technologique : matériel sous-utilisé, coûts énergétiques, renouvellement rapide, pénurie de spécialistes, maintenance de modèles, sécurité de l’infrastructure et complexité MLOps.

La propriété de l’infrastructure n’est pas la propriété de la capacité.

L’actif le plus différenciant peut se trouver ailleurs : règles métier, intégrations, scénarios de test, données structurées, décisions traçables, workflows, modèles de contrôle, procédures et savoir-faire codifié.

L’arbitrage pertinent n’oppose pas mécaniquement API publiques et GPU privés. Il compare, cas par cas, le coût total, la qualité, les risques, la portabilité, la confidentialité et le caractère stratégique des capacités à conserver.

5. Les fournisseurs de LLM eux-mêmes montent dans la chaîne de valeur

Un signal intéressant vient des fournisseurs de modèles. Anthropic ne propose pas seulement de l’inférence : Claude Code, Claude Cowork et Claude Design visent des activités concrètes de développement, de travail documentaire et de création visuelle.

Cette évolution suggère une stratégie de remontée vers les interfaces de travail, les workflows et les produits logiciels. Elle ne démontre pas, à elle seule, une baisse de la part de l’inférence dans leurs revenus : ces produits continuent eux-mêmes à consommer des modèles.

Le changement dans la production logicielle est cependant tangible. Dans une analyse de ses pratiques internes, Anthropic indique qu’en mai 2026, plus de 80 % du code fusionné dans sa base interne avait été rédigé par Claude. Il s’agit d’un chiffre déclaré par l’entreprise sur du code rédigé par l’IA, pas d’une preuve que l’ensemble du cycle de développement serait autonome ou exempt de revue humaine.

La question stratégique ne porte plus seulement sur la génération de code : qui possède les spécifications, les tests, les règles de validation, l’architecture et la capacité de faire évoluer le logiciel ?

6. Le véritable changement : de l’agent lourd en LLM au système déterministe

L’agent LLM-heavy est précieux lorsque le problème est nouveau, ambigu ou peu structuré. Il interprète, explore, propose, génère et aide à diagnostiquer.

Mais pourquoi demander au modèle de réinventer à chaque exécution une règle que l’organisation a déjà comprise et validée ?

Un agent peut évoluer progressivement vers un système hybride :

Exploration par le LLM
  → identification d'un comportement récurrent
  → spécification explicite
  → code, règles, tests et workflows
  → exécution déterministe
  → preuves et supervision
  → LLM réservé aux exceptions et à l'amélioration

J’appelle LLM-marginal cet état où le modèle reste important pour la nouveauté et les exceptions, mais n’est plus le moteur de chaque opération connue.

Il ne s’agit pas de supprimer l’IA générative. Il s’agit de l’utiliser pour produire des capacités qui évitent de payer plusieurs fois pour le même raisonnement.

Les gains de marge ne sont pas automatiques : les coûts de développement, de test, de maintenance, de gouvernance et d’exploitation doivent être inclus dans le calcul. Mais lorsqu’un processus est stable et fréquent, le passage à une exécution plus déterministe peut améliorer la répétabilité, la latence, l’auditabilité et l’économie unitaire.

7. Sans software factory agentique, il n’y a pas d’évolution industrielle

La cible n’est pas une collection d’agents autonomes déconnectés. C’est une software factory agentique permanente capable de capter, formaliser, tester, produire, versionner, déployer, surveiller et améliorer des capacités.

La boucle de capitalisation est simple :

Usage → pattern → spécification
  → code / règle / test / workflow
  → validation → preuve → amélioration
  → capacité réutilisable

L’architecture devient la couche de conversion. Les standards rendent les capacités composables. L’interopérabilité préserve la liberté de remplacement. Le registre de capacités documente leurs propriétaires, versions, dépendances, risques et preuves.

Le mot always-on ne signifie pas que des agents doivent pouvoir modifier librement la production à toute heure. La découverte et les propositions d’amélioration peuvent être continues ; les changements sensibles, eux, doivent passer des tests, des politiques et des approbations proportionnées au risque.

C’est une condition de confiance, pas une limitation de l’ambition.

8. La cybersécurité : la flottabilité du navire

On peut optimiser un bateau pour aller plus vite. Mais sans flottabilité, compartimentage, détection des avaries ni procédures d’urgence, sa vitesse ne sert à rien lorsque survient l’incident.

La cybersécurité n’est pas une option ajoutée à la stratégie IA. Elle est sa condition de navigabilité.

Avec des agents capables d’accéder aux données, de déclencher des outils et de modifier des systèmes, une erreur ou une attaque peut se propager plus vite qu’avec une simple interface conversationnelle.

Le principe de least privilege, la segmentation des accès, la validation déterministe des actions critiques, les journaux d’exécution, la surveillance, les tests de sécurité et la capacité de désactiver ou restaurer un workflow doivent être conçus en amont.

Le NIST AI Risk Management Framework et son profil IA générative fournissent un cadre pour structurer la gestion des risques. L’OWASP Top 10 pour les applications LLM identifie notamment la prompt injection et la divulgation d’informations sensibles parmi les risques à traiter.

La métaphore maritime est utile : l’architecture fixe les compartiments, les droits limitent les mouvements, la télémétrie joue le rôle du radar, les preuves constituent le journal de bord, les plans de reprise préparent l’équipage à l’incident.

On ne sécurise pas le navire après l’avoir lancé. On le conçoit pour rester opérable malgré l’avarie.

9. Un risque moins visible : perdre la relève et la mémoire

La transformation peut également produire une dette humaine.

Si l’on cesse de recruter des juniors parce que les agents réalisent certaines tâches d’entrée de carrière, on réduit les occasions d’apprentissage par la pratique. Si l’on écarte prématurément des seniors jugés obsolètes, on perd du contexte métier, une mémoire des incidents, un jugement sur les exceptions et la connaissance tacite des systèmes.

L’entreprise peut alors devenir apparemment plus productive, mais structurellement moins capable de comprendre, valider et réparer ce qu’elle exécute.

Les juniors ont besoin de parcours d’apprentissage augmentés, dans lesquels ils testent, documentent, challengent et maintiennent les capacités produites avec l’IA. Les seniors ont un rôle essentiel pour expliciter les règles tacites, transmettre les arbitrages, valider les exceptions et définir les standards.

La transmission des compétences n’est donc pas un volet RH périphérique. Elle fait partie de la gouvernance technique et de la continuité opérationnelle.

10. L’enjeu de valorisation : transformer les dépenses IA en actifs défendables

Pour les dirigeants, les investisseurs et les acquéreurs, la question devient : quelle part de la valeur délivrée est propriétaire, réutilisable, portable, sécurisée et démontrable ?

Un agent qui repose intégralement sur des prompts et une plateforme externe peut apporter un service utile. Mais un système doté de règles métier versionnées, de scénarios d’évaluation, de processus intégrés, de preuves d’exécution et d’une capacité d’évolution maîtrisée est un actif plus facilement auditable et transmissible.

Cela peut améliorer la qualité économique et stratégique d’une entreprise. Ce n’est toutefois pas une garantie de multiple de valorisation : la demande, la rétention, la concurrence, les droits de propriété intellectuelle et la rentabilité restent déterminants.

Il faut donc mesurer davantage que le nombre d’utilisateurs ou d’agents :

• Coût complet par workflow et évolution de la marge après automatisation.
• Part d’exécutions déterministes sur les workflows stabilisés, avec une définition stable du périmètre.
• Réutilisation des capacités, fréquence des exceptions et couverture de tests.
• Portabilité réelle entre modèles, fournisseurs et plateformes.
• Traçabilité, résilience et contrôle des actions sensibles.
• Continuité des compétences et capacité interne à maintenir les systèmes.

11. Une feuille de route pour les comités exécutifs

Cinq mouvements peuvent structurer la transformation.

1. Diagnostiquer : cartographier l’AI sprawl, les dépendances fournisseurs, les coûts, les risques cyber et les savoir-faire critiques.
2. Stabiliser : versionner prompts et outils, tracer les exécutions, limiter les permissions et encadrer les actions à risque.
3. Standardiser : définir des contrats d’outils, des formats de preuves, des tests communs et des exigences de portabilité.
4. Durcir : sélectionner les processus récurrents à forte valeur et les convertir progressivement en capacités déterministes.
5. Industrialiser et transmettre : mettre en place la software factory, le registre de capacités, la mesure économique et les binômes humains–agents qui assurent la continuité du savoir.

Le bon indicateur de progression n’est pas « plus d’IA partout ». C’est plus de maîtrise et de valeur réutilisable pour chaque euro investi dans l’IA.

Conclusion : ne pas seulement adopter l’IA, capitaliser sur son usage

L’IA générative peut accélérer les personnes, les équipes et les entreprises. Mais l’adoption seule ne suffit pas à créer un avantage compétitif durable.

Sans architecture, elle peut produire de la fragmentation. Sans interopérabilité, de l’enfermement. Sans software factory, peu de capacités propriétaires. Sans transmission, une perte de mémoire et de relève. Sans cybersécurité, une vulnérabilité systémique.

L’adoption crée l’usage. L’architecture capte l’apprentissage. Les standards permettent l’échelle. L’interopérabilité protège la liberté stratégique. La cybersécurité assure la navigabilité. La software factory produit les actifs. La transmission préserve la maîtrise.

La véritable transformation n’est pas de multiplier les agents. C’est d’acquérir la capacité industrielle de faire évoluer son propre logiciel, ses processus et ses compétences, grâce à l’IA — sans abandonner le contrôle de ce qui fait la valeur de l’entreprise.