Le véritable risque de l’IA en entreprise n’est pas l’usage non encadré, mais le manque de contexte

Le contenu de cette page a été traduit automatiquement par un service tiers.

Lorsque seulement 40 % des entreprises disposent d’un accès officiel aux LLM, mais que plus de 90 % des employés utilisent déjà l’IA, la question n’est plus celle de l’adoption. Il s’agit de savoir si l’IA fonctionne dans une réalité produit gouvernée.

La plupart des entreprises considèrent encore l’utilisation non autorisée de l’IA comme un problème de politique. Je pense que cela passe à côté du signal le plus intéressant.

Lorsque les collaborateurs contournent les outils officiels, ils vous disent généralement quelque chose que l’organisation ne veut pas entendre : la demande est déjà là, et l’expérience validée ne répond pas à ce besoin.

C’est la conclusion la plus marquante que je tire de l’article de Harvard Business Review qui a inspiré ce texte, The Hidden Demand for AI Inside Your Company. Les chiffres sont difficiles à ignorer. Seules 40 % des entreprises ont souscrit à des abonnements LLM officiels, pourtant plus de 90 % des employés de ces entreprises déclarent utiliser des outils d’IA personnels pour leur travail. Ce n’est pas un comportement marginal. C’est une demande latente qui franchit les barrières.

Pour la plupart des fonctions de l’entreprise, cela crée un problème de gouvernance. Dans les organisations produit, cela crée quelque chose de plus important.

Car dans l’entreprise, les équipes ne se contentent pas d’améliorer des emails ou de résumer des documents génériques. Elles travaillent à travers des exigences, des nomenclatures (BOM), des modifications d’ingénierie, des données fournisseurs, des événements qualité, des plans de fabrication, l’historique de service, et le réseau dense de relations qui définissent un produit. C’est là que la discussion devient sérieuse. Très rapidement.

Le problème n’est pas l’utilisation de l’IA. C’est l’utilisation de l’IA sans vérité produit.

C’est la partie que, selon moi, de nombreuses entreprises sous-estiment encore.

Un outil d’IA généraliste peut être impressionnant tout en étant erroné sur les aspects qui comptent réellement en ingénierie. Il peut ne pas savoir quelle version est la plus récente. Il peut ne pas comprendre l’effectivité. Il peut ne pas reconnaître si une exigence a été remplacée, si un problème qualité est toujours ouvert, ou si l’utilisateur devrait même avoir accès aux données sous-jacentes. Il ne comprend pas naturellement les états de publication, la traçabilité, la logique de configuration ou l’impact des modifications en aval.

Et dans des environnements fortement axés PLM, ces détails ne sont pas des cas limites. Ils constituent le travail.

Le risque central n’est pas que les employés utilisent l’IA. C’est qu’ils utilisent l’IA en dehors du contexte gouverné qui rend les décisions d’ingénierie fiables.

C’est là que se situe l’écart réel. Pas dans la qualité des modèles. Dans la qualité du contexte.

Pourquoi l’IA fantôme est un signal, pas seulement une violation

L’article HBR avance ici un argument utile. Les entreprises répondent souvent à l’IA fantôme par des restrictions, de la surveillance et du contrôle, alors que ce comportement est en réalité la preuve d’un besoin non satisfait. Les employés recherchent de la rapidité, de la synthèse, de la reconnaissance de schémas et une réduction des frictions. Ils essaient simplement de faire leur travail.

Je pense que cette leçon résonne encore plus fortement dans l’ingénierie numérique.

Si les ingénieurs, les équipes qualité, les planificateurs de production et les responsables de programme utilisent des outils d’IA grand public dans leur travail quotidien, ils révèlent là où l’organisation génère trop de friction. Recherche lente. Réutilisation des connaissances insuffisante. Systèmes fragmentés. Contexte enfermé dans des silos. Trop de transferts. Trop peu de traçabilité au moment où une décision doit être prise.

C’est pourquoi cette problématique est directement liée à une stratégie de continuité numérique. Une continuité numérique n’a pas de valeur simplement parce qu’elle paraît moderne. Elle est précieuse parce qu’elle structure le contexte. Elle relie l’exigence au modèle système, la pièce à la nomenclature, la modification au dossier qualité, le fournisseur à l’impact de conformité, et les problèmes de service à la conception. Sans ce contexte connecté, l’IA peut générer du langage. Avec lui, elle peut réellement soutenir le travail d’ingénierie.

La différence est majeure.

La prochaine phase de l’IA d’entreprise se jouera sur l’architecture du contexte

Les leaders de l’IA d’entreprise ne seront pas simplement ceux qui lancent le plus de projets pilotes. Nous avons déjà suffisamment de pilotes. Ce qui manque, c’est le contexte opérationnel.

Les entreprises qui prendront de l’avance seront celles qui connecteront l’IA aux données produit gouvernées, à la logique du cycle de vie et aux contrôles d’accès. Autrement dit, elles traiteront l’IA comme une composante du modèle opérationnel, et non comme un assistant détaché évoluant à côté du système réel.

Cela a des implications à tous les niveaux.

Pour les responsables PLM, cela signifie que la continuité des données produit cesse d’être une préoccupation de back-office et devient un enjeu de préparation à l’IA. Pour les équipes d’ingénierie numérique, cela souligne l’importance de la traçabilité du cycle de vie et des liens inter-domaines. Pour les initiatives MBSE et MBE, cela renforce l’intérêt de modèles structurés et de représentations connectées exploitables par les machines, pas uniquement par les humains. Pour les architectes d’entreprise, cela met la pression sur l’interopérabilité, car une couche d’IA reposant sur des référentiels déconnectés héritera de leur fragmentation.

Des données désordonnées produisent des résultats désordonnés. Simplement plus rapidement.

La gouvernance reste essentielle, mais elle doit évoluer

Un point que j’ai apprécié dans l’article HBR est l’insistance sur la responsabilité humaine. Le modèle de BBVA, tel qu’il y est décrit, ne considère pas l’IA comme un acteur autonome. Les humains restent responsables, et les modifications directes des systèmes centraux sont limitées. Ce principe est encore plus important dans les environnements d’ingénierie.

Non pas parce que les organisations d’ingénierie doivent ralentir. Elles ne le doivent pas. Mais parce qu’elles ont besoin d’une accélération maîtrisée.

Cela implique plusieurs choses. L’IA doit disposer d’un accès encadré, et non d’un accès libre aux propriétés intellectuelles sensibles. Elle doit travailler avec des données actuelles et autorisées, et non avec des exports obsolètes. Elle doit s’inscrire dans des workflows observables avec des responsabilités claires. Et elle doit fonctionner dans un système permettant de tracer, contester et auditer les décisions.

Si cela paraît moins spectaculaire que les assistants IA conçus pour les démonstrations, c’est très bien. C’est le but. Une IA d’entreprise fiable est généralement moins théâtrale et beaucoup plus architecturée.

Ce que cela signifie aujourd’hui

La question pratique n’est plus de savoir si l’IA a sa place dans l’ingénierie. Ce débat est terminé.

La véritable question est de savoir si votre environnement d’ingénierie est prêt à fournir le contexte dont l’IA a besoin pour être utile sans devenir risquée.

C’est une question plus difficile, car elle oblige les entreprises à regarder sous la surface. Vers la qualité des données. Les permissions. La maturité des processus. La complétude de la continuité numérique. Et vers la question de savoir si le PLM fonctionne réellement comme un système de vérité produit gouvernée, ou simplement comme un référentiel supplémentaire.

C’est là que, selon moi, le marché évolue discrètement. L’adoption de l’IA dans l’ingénierie mettra de plus en plus en évidence la différence entre les organisations disposant de fondations de cycle de vie connectées et celles reposant sur des outils fragmentés. Les premières pourront intégrer l’IA dans des workflows réels. Les secondes continueront à produire des démonstrations impressionnantes et des notes de conformité prudentes.

Conclusion

Non, je ne considérerais pas l’IA fantôme comme le principal danger.

Le véritable danger est de laisser l’IA fonctionner sans contexte produit, sans discipline de cycle de vie et sans gouvernance adaptée au travail d’ingénierie.

C’est l’enjeu stratégique qui se cache sous la vague actuelle d’expérimentation. Et c’est pourquoi la continuité numérique, le PLM, le MBSE, le MBE et la stratégie de données d’ingénierie comptent aujourd’hui encore davantage dans les discussions sur l’IA qu’il y a un an. Non pas comme des sujets secondaires. Mais comme la fondation.

Car l’avenir ne sera probablement pas une IA à côté du système produit.

Ce sera une IA intégrée au système produit, opérant à partir d’un contexte gouverné plutôt que d’hypothèses.

Et les organisations qui comprendront cela en premier ne feront pas que réduire les risques. Elles prendront de meilleures décisions, plus rapidement, avec une traçabilité accrue et beaucoup moins de bruit.