L’intelligence artificielle ne se déploie pas comme un logiciel classique. Son efficacité dépend moins de sa puissance que de son intégration dans les processus existants, une réalité souvent ignorée lors des premières démonstrations. Pourtant, selon l’analyse de Guy de Lussigny dans IA opérationnelle !, la majorité des échecs ne viennent pas d’un manque de technologie, mais d’une méconnaissance des contraintes architecturales et organisationnelles. Un audit rigoureux révèle que les coûts cachés – intégration, sécurité, supervision – peuvent transformer un projet prometteur en fardeau opérationnel. Sans cette étape, même une solution performante sur le papier risque de devenir ingérable à grande échelle. La question n’est pas si l’IA peut être utile, mais comment la préparer pour qu’elle serve durablement.
L’audit : quand les systèmes hérités deviennent des freins invisibles
Guy de Lussigny souligne que les systèmes anciens ne sont pas systématiquement obsolètes, mais leur dette technique – interfaces non documentées, dépendance à des experts, traitements manuels – peut rendre l’intégration d’une IA coûteuse et risquée. Par exemple, une application critique mais mal maintenue peut exiger des connecteurs provisoires ou des extractions contrôlées, augmentant les délais et les coûts sans que cela soit anticipé. L’audit doit donc cartographier ces contraintes pour éviter de promettre des résultats impossibles à industrialiser. Une dette technique non identifiée se transforme en promesse impossible : un pilote peut sembler fonctionnel, mais son passage à l’échelle révèle des intégrations non budgétées ou une supervision absente. La rigueur de cette étape évite ainsi les déceptions post-déploiement, où la complexité réelle éclate au grand jour. L’exemple du cas fil rouge Novalia Services illustre ce principe : un SI hétérogène, avec des dossiers locaux et des droits d’accès non alignés, limite le périmètre du pilote à un corpus maîtrisé pour éviter les risques juridiques et opérationnels.
Sécurité et gouvernance : l’IA n’est pas une expérimentation personnelle
L’auteur insiste sur un point souvent négligé : la sécurité d’un service IA repose sur des mécanismes classiques – identité, habilitations, gestion des secrets – mais appliqués avec une exigence accrue. Un assistant qui ignore les droits d’accès peut exposer des informations confidentielles, tandis qu’une automatisation utilisant un compte technique trop large crée des risques d’abus. L’audit doit vérifier si l’entreprise maîtrise déjà ces pratiques : versionnage des prompts, tests de sécurité avant production, ou encore journalisation des actions. Sans cela, une solution IA devient un composant non gouverné du système d’information, comme le note Guy de Lussigny. Par exemple, l’indexation documentaire chez Novalia Services doit respecter les profils utilisateurs pour éviter toute fuite interne. Ces vérifications ne sont pas théoriques : elles déterminent si un pilote peut être industrialisé ou s’il restera une initiative isolée, sans support ni maintenance structurée.
Les coûts cachés : quand l’intégration transforme un projet rentable en gouffre
Les démonstrations d’IA mettent souvent en avant les coûts visibles – licence ou abonnement au modèle –, mais occultent les dépenses réelles : intégration aux applications existantes, nettoyage des données, supervision, tests et formation. Selon l’auteur, ces coûts cachés peuvent rendre un cas d’usage initialement attractif disproportionné une fois déployé. Par exemple, connecter un assistant à un SI hérité peut exiger des développements spécifiques ou des adaptations de flux, sans que cela soit anticipé dans le business case initial. L’audit doit donc évaluer ces contraintes dès la phase de diagnostic pour éviter des arbitrages trompeurs. Chez Novalia Services, la fraîcheur des sources et la journalisation des questions posées n’étaient pas prévues initialement, ce qui aurait pu rendre le pilote ingérable sans une recadrage précoce. La clé réside dans l’honnêteté : un projet viable à petite échelle peut devenir irréaliste dès qu’il rencontre les limites du SI.
Portabilité et réversibilité : la dépendance fournisseur, un risque sous-estimé
Guy de Lussigny met en garde contre une dépendance à un fournisseur ou à un modèle qui n’est pas contractualisée ni réversible. Une solution IA peut reposer sur des formats de données propriétaires, des API non documentées ou des compétences internes limitées pour changer d’outil. L’audit doit poser des questions simples : les données peuvent-elles être exportées ? Les prompts et configurations sont-ils reproductibles avec un autre modèle ? Les contrats prévoient-ils une sortie ? Sans ces garanties, l’entreprise risque de se retrouver prisonnière d’un écosystème dont elle ne maîtrise plus les règles. Par exemple, chez Novalia Services, l’absence de plan pour exporter les prompts et les journaux aurait compliqué un changement futur. Ces vérifications permettent d’éviter des engagements à long terme sans issue, où le coût de la réversibilité n’est découvert qu’après le déploiement.
L’IA fantôme : ce que l’entreprise utilise déjà sans le savoir
Une révélation de l’auteur : les entreprises utilisent souvent de l’IA sans en avoir conscience. Des licences sont achetées localement, des assistants génératifs testés avec des comptes individuels, ou des données copiées dans des outils publics sans contrôle. Ce phénomène, qualifié d’IA fantôme, expose à des risques – fuites d’informations, coûts dispersés, absence de traçabilité – tout en répondant à des besoins réels : gagner du temps ou compenser un manque d’outils internes. L’enjeu n’est pas d’interdire ces usages, mais de les recenser pour en limiter les dangers. Par exemple, un collaborateur utilisant un outil non déclaré peut introduire une dépendance non maîtrisée ou exposer des données sensibles. L’audit doit donc identifier ces pratiques sans bloquer l’innovation, en distinguant ce qui est acceptable – comme un pilote local sans données critiques – de ce qui nécessite un recadrage immédiat.
Transformer l’IA en résultats concrets exige une approche méthodique : auditer les contraintes techniques et organisationnelles avant tout déploiement, évaluer les coûts cachés et les risques juridiques, et s’assurer que la gouvernance suit le rythme de l’innovation. Comme le rappelle Guy de Lussigny, une démonstration isolée ne prouve pas la faisabilité opérationnelle. La clé réside dans l’honnêteté des diagnostics et la préparation en amont – sans quoi même les projets les plus prometteurs risquent d’échouer sur des obstacles évitables. Découvrir le livre et lire un extrait chez le libraire, avec ce lien exact : https://www.amazon.fr/dp/B0HDGY2CJT?utm_source=wordpress&utm_medium=organic&utm_campaign=ariane&utm_content=2026-10-07-WORDPRESS-ULTIMATEPOCKET-COM-07.
#IAOpérationnelle #TransformationDigitale #DataGovernance
