Les risques réels de l'IA en industrie, et pourquoi le local les réduit

L'intelligence artificielle se vend sur ses bénéfices : du temps gagné, des historiques enfin exploitables, des décisions mieux préparées. Ces bénéfices sont réels.

Mais un directeur d'usine n'achète pas une promesse, il évalue un risque. Et sur ce terrain, le discours commercial devient soudain très discret.

Les risques d'une IA en environnement industriel existent, ils sont précis, et la plupart ne viennent pas de la technologie elle-même : ils viennent de la façon dont elle est déployée, et surtout de l'endroit où finit la donnée.

Voici les neuf risques réels, ce que chacun produit concrètement, et lequel se réduit en gardant la main sur la donnée.

Tableau faisant défiler horizontalement sur petit écran.

La donnée qui s'échappe : le risque le plus sous-estimé ?

C'est le premier, et le plus sous-estimé. La plupart des services d'IA grand public traitent les données en les envoyant sur les serveurs d'un fournisseur.

Pour rédiger un e-mail, sans conséquence. Pour un site industriel, c'est un transfert de matière sensible hors de vos murs.

Ce qui part n'est pas anodin, et change de nature selon le métier :

• En chimie et pétrochimie, un rapport d'inspection contient les épaisseurs, les boucles de corrosion et les mécanismes de dégradation : la carte des points faibles du parc.
• En agroalimentaire, une séquence de nettoyage en place relève du savoir-faire autant que de la sécurité sanitaire.
• En pharmaceutique, un paramètre de procédé qualifié touche à ce qui est le plus encadré de l'usine.

Agrégées, ces informations décrivent votre outil de production mieux qu'un concurrent ne le pourrait.

Et le risque ne disparaît pas par une simple interdiction. Là où l'informatique bloque les outils cloud, un technicien copie un extrait de rapport depuis son téléphone, persuadé de gagner du temps.

C'est le shadow AI : l'IA qui entre par la porte de derrière, sans contrôle, en emportant précisément les données qu'on voulait protéger. D'où viennent ces fuites et comment les cadrer est traité dans les fuites de données par l'IA viennent de vos équipes et de vos prestataires.

L'erreur invisible : pourquoi est-elle si dangereuse ?

Une IA générative peut produire une réponse fausse avec le même aplomb qu'une réponse juste. On parle d'hallucination.

Sur une conversation ordinaire, c'est sans gravité. Sur une donnée technique, c'est une bombe à retardement.

Imaginez un assistant qui, en résumant un rapport, restitue une épaisseur résiduelle légèrement différente de celle mesurée, ou rattache un constat au mauvais repère d'équipement. Personne ne s'en aperçoit : la sortie est propre et plausible.

La valeur fausse entre alors dans un historique, sert de base à un calcul de vitesse de corrosion, puis à une échéance de réinspection. L'erreur ne se voit pas quand elle est commise : elle se voit, éventuellement, le jour où l'équipement est contrôlé plus tard qu'il n'aurait dû l'être.

C'est pourquoi la frontière entre ce qu'une IA prépare et ce qu'elle décide n'est pas une précaution de principe : c'est la protection contre l'erreur invisible. Une IA qui ne montre pas d'où vient chaque information ne peut pas servir à décider, parce qu'on ne peut pas vérifier ce qu'on ne peut pas retracer.

La dépendance au fournisseur : que vous reste-t-il s'il part ?

Un outil loué dans le cloud n'est jamais tout à fait le vôtre. Le fournisseur peut changer ses conditions, augmenter ses prix, modifier son modèle, restreindre un usage, ou disparaître.

Le jour où cela arrive, vous découvrez ce que vaut réellement votre autonomie : un flux de travail construit autour d'un service que vous ne contrôlez pas s'arrête avec lui.

Ce risque porte un nom que connaissent les responsables ayant vécu une migration de GMAO forcée : le verrouillage fournisseur. Vos données, votre historique, vos automatismes finissent enfermés dans un format dont sortir coûte cher.

La question à se poser avant de démarrer n'est donc pas seulement « est-ce que ça marche », mais « qu'est-ce qui m'appartient encore si le fournisseur s'en va ». C'est l'une des questions qu'un dossier économique sérieux doit trancher.

La sécurité des réseaux : une porte de plus ouverte ?

Toute connexion nouvelle entre votre système d'information et l'extérieur est une porte de plus. Un outil d'IA cloud mal intégré peut devenir un pont entre votre bureautique et votre réseau industriel, précisément là où la règle est de cloisonner.

La séparation entre l'informatique de gestion et l'informatique de production n'est pas un caprice de spécialiste : c'est ce qui empêche qu'un incident sur un poste bureautique n'atteigne un automate de ligne.

Le risque n'est pas théorique pour les sites où la disponibilité et la sécurité priment. Ajouter de l'IA sans se demander où passent les flux, et ce à quoi l'outil accède, revient à percer une cloison sans regarder ce qu'il y a de l'autre côté.

La sur-confiance : le risque humain le plus coûteux ?

Celui-ci est plus discret, et souvent le plus coûteux. Un outil qui donne des réponses fluides inspire confiance, et cette confiance se transforme vite en habitude de ne plus vérifier.

Le jour où l'outil se trompe, l'erreur passe, parce que plus personne ne la contrôle vraiment.

En maintenance et en inspection, la signature engage une responsabilité qui ne se délègue pas à une machine. Un outil qui prétend décider seul ne fait pas gagner du temps : il déplace vers celui qui signe une responsabilité qu'il n'a plus les moyens d'assumer.

La bonne pratique inverse la logique : l'IA prépare, propose, signale ; l'humain garde la décision et la vérification.

La non-conformité : êtes-vous prêt pour un contrôle ?

Le cadre se resserre. Deux textes structurent désormais l'usage :

• Le règlement européen sur l'IA (AI Act) classe les usages selon leur niveau de risque et impose, pour les plus sensibles, documentation, supervision humaine et robustesse.
• Le RGPD s'applique dès qu'une donnée personnelle entre dans le périmètre, un nom d'opérateur dans un compte rendu par exemple.

Déployer un outil sans savoir où passent les données, ni qui décide, c'est s'exposer à ne pas pouvoir répondre le jour où la question est posée.

Ces textes se citent par leur objet, jamais par un numéro d'article ou un seuil qu'on n'aurait pas vérifié : une obligation inventée décrédibilise autant qu'une donnée fausse.

Le projet mort-né : pourquoi la plupart échouent ?

Il existe un risque dont on parle peu parce qu'il n'est pas spectaculaire : celui du projet qui ne produit jamais rien. En industrie, la plupart des initiatives d'IA n'échouent pas sur la technologie, mais sur la mise en œuvre.

Le scénario est connu, et se déroule toujours de la même façon :

1. Un outil est choisi sur une démonstration flatteuse, sans partir d'un besoin métier précis.
2. On découvre que les données visées sont dispersées, mal renseignées, parfois enfermées dans le tableur d'un technicien parti à la retraite.
3. Les équipes de terrain, non associées, voient arriver un outil de plus qu'on leur impose, et ne l'utilisent pas.
4. Quelques mois plus tard, le pilote est enterré, avec une conclusion fausse : « l'IA ne marche pas chez nous ».

Ce n'est pas l'IA qui n'a pas marché, c'est le projet qui a été lancé à l'envers.

Ce risque se prévient en amont : partir d'une tâche réelle qui coûte du temps, vérifier que les données existent et sont exploitables, associer ceux qui utiliseront l'outil, et déployer petit avant de généraliser. C'est tout l'objet de la conduite du changement d'un projet d'IA et d'un premier déploiement mené sur quatre-vingt-dix jours.

La boîte noire : peut-on auditer la décision ?

Un dernier risque, plus insidieux : celui d'un outil qui produit des conclusions sans qu'on puisse expliquer comment il y arrive. En industrie, une décision se justifie.

Devant un auditeur, devant une direction, devant une autorité, il faut pouvoir dire pourquoi tel équipement a été maintenu en service, sur quelles données, selon quel raisonnement.

Un modèle qui répond sans montrer ses sources transforme chaque résultat en pari. Si personne ne peut remonter de la conclusion à la mesure d'origine, l'outil n'est pas auditable, et ce qui n'est pas auditable n'a pas sa place dans une chaîne de décision où la traçabilité est la règle.

Le risque n'est pas seulement de se tromper : c'est de ne pas pouvoir démontrer qu'on a eu raison. Une IA utile en industrie est une IA dont on peut vérifier chaque affirmation, pas un oracle qu'on croit sur parole.

Le coût qui dérape : cloud ou local ?

Un service cloud se facture à l'usage, et cette facture a une fâcheuse tendance à croître avec l'adoption. Ce qui paraissait modique sur un pilote devient une ligne budgétaire significative une fois l'outil déployé à l'échelle du site : chaque document traité, chaque requête, s'ajoute au compteur.

Le coût réel d'un outil ne se lit pas sur son tarif d'appel, mais sur ce qu'il coûtera le jour où il sera vraiment utilisé.

À l'inverse, un déploiement local concentre l'investissement au départ, dans le matériel et la mise en place, puis se stabilise. Ni l'un ni l'autre n'est gratuit, et prétendre le contraire serait malhonnête.

Mais la structure de coût n'est pas la même, et un dossier économique sérieux doit comparer non pas deux tarifs d'entrée, mais deux trajectoires sur la durée. Le risque, ici, n'est pas de payer : c'est de payer sans l'avoir anticipé.

La racine commune, et la réponse

Reprenez ces risques. La plupart, la fuite, la dépendance, la faille de sécurité, la boîte noire, une partie de la non-conformité, et même l'erreur invisible quand on ne peut pas retracer la source, tiennent au même point : la donnée et le modèle sont hors de votre contrôle.

C'est ce qui explique pourquoi la réponse n'est pas d'ajouter une couche de précaution après coup, mais de changer l'architecture.

Un outil sur mesure, entraîné et déployé en local, hors cloud, garde la donnée sur site, ne dépend d'aucun service extérieur, et permet de retracer ce qu'il produit. Il ne rend pas le risque nul, aucun outil ne le fait, mais il élimine ceux qui viennent d'avoir confié l'essentiel à un tiers.

C'est précisément la logique d'une IA responsable pensée dès sa conception : les risques ne se corrigent pas, ils se conçoivent en amont.

Un directeur d'usine ne cherche pas l'outil le plus impressionnant en démonstration, mais celui dont il pourra répondre dans six mois, devant un auditeur comme devant sa direction. Cet outil-là ne se rattrape pas en fin de projet : il se décide au début, dans le choix de l'endroit où vivent vos données et de qui, au bout du compte, en garde la maîtrise.