Je montre à l'équipe d'un directeur technique dans une entreprise d'infrastructure comment fonctionne Claude Code. Un workflow agentique — le modèle lit le code, analyse le contexte, propose des modifications, lance les tests. Le directeur hoche la tête et dit : « Intéressant. Nous pouvons le faire nous-mêmes. »
Trois mois plus tard, quelqu'un de cette même entreprise m'appelle. Pas le directeur — quelqu'un de l'équipe. Il veut discuter parce qu'« il y a un problème de sécurité ». Il s'avère que leur équipe interne a commencé à « déployer l'IA » — en envoyant des données de production de clients vers des modèles externes par API, sans sandboxing, sans classification des données, sans aucune gouvernance. Le code qu'ils généraient avec l'aide de l'IA entrait en production sans code review. Sans tests. Sans staging.
« On peut le faire nous-mêmes » s'est transformé en fuite de données et en code que personne ne comprend.
Le problème n'est pas dans l'ambition — il est dans le processus
Je n'ai rien contre l'ambition. Au contraire, je la respecte. Le problème est que de nombreuses entreprises IT — surtout celles qui font de l'infrastructure, pas du logiciel — n'ont pas les processus de développement fondamentaux qui sont une condition nécessaire pour travailler avec l'IA en toute sécurité.
Je parle du SDLC — Software Development Life Cycle. De la code review. Des tests automatisés. Des environnements de test séparés de la production. De la classification des données et de la gouvernance. Du fait qu'avant que quoi que ce soit n'arrive en production, cela passe par plusieurs paires d'yeux et des contrôles automatisés.
Ces processus ne sont pas une formalité. C'est une infrastructure de sécurité. Et un modèle d'IA est exactement aussi bon que le processus dans lequel il opère.
Ce que ne savent pas les entreprises qui « peuvent faire seules »
D'après mes observations, les entreprises d'infrastructure qui déclarent être prêtes à déployer l'IA par elles-mêmes ignorent généralement plusieurs choses :
Comment les modèles d'IA sont entraînés et sur quelles étapes du processus SDLC ils basent leur fonctionnement. Des outils comme Copilot, Claude Code ou Cursor ne génèrent pas du code dans le vide. Leur efficacité dépend du contexte — de la structure du dépôt, de la qualité du code, de l'existence d'une documentation technique et de tests. Sans cela, ils génèrent des déchets, et l'entreprise n'a pas d'outils pour le vérifier.
Où finissent les données d'entreprise quand elles arrivent dans le modèle. L'absence de data governance signifie que personne ne sait quelles données sont confidentielles, lesquelles peuvent quitter l'organisation, et lesquelles ne devraient même pas atteindre un modèle interne. J'ai vu des situations où des données clients — sensibles, couvertes par des accords de confidentialité — étaient envoyées vers des API publiques sans aucun contrôle.
Que « ça fonctionne » n'est pas la même chose que « c'est sécurisé ». Le code généré par l'IA peut fonctionner. Il peut passer des tests manuels basiques. Mais sans code review, sans analyse statique, sans tests de régression — c'est une bombe à retardement. Aujourd'hui ça fonctionne. Dans un mois, ça explose en production.
« On le fait nous-mêmes » — la phrase la plus coûteuse de l'IT
Je ne prétends pas qu'un consultant externe est toujours nécessaire. Je prétends que si une entreprise n'a pas de processus de développement mature, déployer l'IA sans supervision est un risque métier, pas de l'innovation.
Les entreprises qui n'ont jamais eu de discipline de processus SDLC se retrouvent soudainement avec des outils qui génèrent du code à une vitesse qu'aucun programmeur ne peut atteindre. Cela semble être de l'accélération. En pratique, c'est une accélération vers un mur — parce que personne ne contrôle la qualité de ce qui est produit.
Le marché dit « démocratisation de l'IA — tout le monde peut ! ». Et c'est vrai — tout le monde peut commencer. Mais tout le monde ne sait pas le faire de manière sécurisée et pertinente. Surtout les entreprises qui ne distinguent pas le staging de la production.
Ce qui devrait venir en premier
Avant qu'une entreprise ne commence à déployer l'IA dans ses produits et services, elle devrait répondre à plusieurs questions :
- Avons-nous un processus de développement (SDLC) défini et l'appliquons-nous ?
- Avons-nous une classification des données et savons-nous ce qui peut quitter l'organisation ?
- Tout code — qu'il soit écrit par un humain ou généré par une machine — passe-t-il par la code review et les tests ?
- Avons-nous des environnements de développement, de test et de production séparés ?
- Quelqu'un dans l'entreprise comprend-il comment fonctionnent les modèles d'IA et quelles sont leurs limites ?
Si la réponse à l'une de ces questions est « non » ou « je ne sais pas » — ce n'est pas le moment de « le faire soi-même ». C'est le moment de faire un audit de préparation et de faire face honnêtement à ce qui manque.
Collaboration, pas ego
Les meilleurs déploiements d'IA que j'ai vus combinaient l'ambition de l'entreprise avec une supervision externe du processus. Pas parce que l'entreprise était incompétente. Mais parce que quelqu'un de l'extérieur voit les angles morts que l'équipe interne ne perçoit pas — parce qu'elle est trop proche.
L'IA n'est pas un espace où il vaut la peine de prouver qu'« on peut faire seul ». C'est un espace où il vaut la peine de prouver que l'on est capable de collaborer — de manière sécurisée, avec un processus, avec une responsabilité sur les données et la qualité.
Chère lectrice, cher lecteur. Si vous reconnaissez ces schémas dans votre entreprise ou chez vos fournisseurs — parlons-en. Je vous invite à me contacter — Leszek Giza.