Le modèle, c'est la partie visible. Ce que personne ne voit, c'est tout ce qui doit exister autour pour qu'il tourne en production dans un environnement régulé. Et c'est précisément là que la plupart des projets IA en grande entreprise s'enlisent.
Le ratio qui dérange
Quand un grand groupe lance un projet IA, l'essentiel du temps de réunion porte sur le choix du modèle : GPT-4o ou Claude ? Fine-tuning ou RAG ? Open source ou API propriétaire ? C'est compréhensible, c'est concret, ça se présente bien en comité.
Pourtant, dans la réalité d'un déploiement en production au sein d'une banque, d'un assureur ou d'un grand groupe industriel, le modèle représente environ 20% du problème. Les 80% restants, c'est tout ce qui l'entoure : qui a accès à quoi, où tournent les données, qui est responsable si ça dérive, comment on prouve après coup que la décision était traçable.
Ce n'est pas une opinion. C'est ce que Lucid-Lab observe projet après projet, et c'est ce que le cadre réglementaire européen est en train de formaliser.
EU AI Act : le calendrier qui s'impose
L'EU AI Act n'est pas un texte hypothétique. Depuis août 2025, les obligations sur les modèles d'IA à usage général sont applicables. Concrètement, cela concerne déjà les modèles de fondation déployés dans les systèmes internes : traçabilité de l'entraînement, documentation technique, obligations de transparence.
À partir d'août 2026, le régulateur européen pourra sanctionner : amendes, retraits de systèmes, obligations de remédiation. Les règles spécifiques aux systèmes à haut risque, elles, ont été repoussées à fin 2027 par le Digital Omnibus (encore en cours d'adoption), mais elles arrivent.
| Échéance | Ce qui s'applique |
|---|---|
| Août 2025 | Obligations sur les modèles d'IA à usage général |
| Août 2026 | Sanctions effectives, retraits possibles |
| Fin 2027 | Systèmes à haut risque (finance, RH, assurance...) |
Pour une PME qui déploie un outil d'automatisation interne, c'est aujourd'hui un bonus d'être en conformité. Pour une banque qui utilise l'IA dans la gestion des risques, c'est la condition d'entrée en production. La différence n'est pas dans la volonté : c'est dans les conséquences si ça dérape.
Ce que "gouvernance" veut vraiment dire
Le mot est souvent utilisé comme paravent. "On fait de la gouvernance" peut signifier qu'on a une slide avec des cases. Ce n'est pas de ça dont on parle.
La gouvernance d'un système IA en environnement régulé, c'est un ensemble de réponses concrètes à des questions précises.
Hébergement et souveraineté des données
Où tournent les données quand le modèle traite une requête ? Sur quels serveurs ? Dans quelle juridiction ? Pour un assureur qui envoie des données clients vers une API externe hébergée hors EU, la réponse "on a accepté les CGU" ne suffit plus. Il faut un contrat de traitement des données conforme au RGPD, un hébergeur avec certification adéquate, et souvent une architecture qui évite que les données brutes quittent l'infrastructure de l'entreprise.
Chez Lucid-Lab, on a eu ce débat sur le projet Périscope, un système de monitoring déployé chez un grand groupe : le choix d'hébergement a conditionné l'architecture bien avant qu'on parle de quel modèle utiliser.
Matrice d'accès
Qui peut interroger le système ? Avec quels droits ? Un commercial peut-il accéder aux mêmes données qu'un analyste risque ? La matrice d'accès n'est pas qu'une question de sécurité informatique, c'est une question de responsabilité : si une décision erronée est prise à partir d'une requête mal formulée par quelqu'un qui n'aurait pas dû avoir accès à ce contexte, qui porte la responsabilité ?
Logs et traçabilité des décisions
Ce point est systématiquement sous-estimé en phase de conception. En phase de production, c'est la première chose que le régulateur demande et la première chose que le service juridique réclame quand quelque chose se passe mal.
La question n'est pas "est-ce que le système fonctionne bien ?" mais "est-ce qu'on peut reconstituer, six mois plus tard, pourquoi le système a produit cette output à ce moment-là, avec ces données-là ?" C'est ce qu'on appelle la traçabilité des décisions, et ça implique des choix d'architecture dès le départ, pas en retrofit.
C'est pour ça que l'observabilité fait partie de ce que Lucid-Lab livre à chaque projet, au même titre que le code et le schéma de base de données. Si vous voulez comprendre ce que ça implique concrètement, la méthode Build & Run est documentée ici.
Le vrai test d'un système prêt à passer en production
Il existe une question simple, mais redoutable, qu'on pose systématiquement avant de parler de ROI : "Et si ça dérape, qu'est-ce qui se passe ?"
Un système IA bien conçu permet de répondre à cette question sans improviser :
- Le système détecte l'anomalie et l'escalade automatiquement vers un humain identifié
- Les logs permettent de rejouer exactement ce qui s'est passé
- L'accès au système peut être restreint ou coupé en moins de 15 minutes
- La responsabilité est documentée et attribuée (pas juste "le prestataire")
- Les données impactées sont identifiables et isolables
Si une seule de ces réponses est floue au moment de la mise en production, le projet n'est pas prêt. Pas parce que le modèle est mauvais. Parce que l'environnement dans lequel il tourne n'est pas contrôlé.
Ce type de vérification fait directement écho à ce qu'on décrit dans notre approche du transfert de système IA : un système livré sans réponses à ces questions est un système qui sera abandonné ou contourné dans les six mois.
Pourquoi la plupart des prestataires font l'inverse
Ce n'est pas de la mauvaise foi. C'est un problème de structure d'incitation.
Un prestataire est évalué sur ce qu'il livre de visible : une démo qui impressionne, des métriques de performance du modèle, un prototype fonctionnel. La gouvernance, elle, ne se voit pas dans une démo. Elle se voit quand le projet est en production depuis six mois, quand le premier incident survient, quand le RSSI pose des questions.
Le résultat : les équipes techniques construisent quelque chose qui fonctionne dans un environnement contrôlé, et laissent les questions de gouvernance à "plus tard". Ce "plus tard" a un coût réel.
| Ce qu'on bâcle au départ | Ce que ça coûte en production |
|---|---|
| Architecture de logs absente | Reconstruction manuelle, 3 à 8 semaines d'audit |
| Hébergement non conforme | Remigration complète, interruption de service |
| Matrice d'accès imprécise | Incident de sécurité ou blocage RGPD |
| Pas de runbook | Dépendance totale au prestataire initial |
Ces chiffres sont des ordres de grandeur issus de projets réels, pas des projections théoriques.
Ce que ça change concrètement dans l'approche projet
La gouvernance n'est pas une couche qu'on ajoute par-dessus un système existant. C'est une contrainte de conception qui s'impose dès le cadrage.
Concrètement, ça veut dire :
- Identifier le niveau de risque du système dès le début (classification EU AI Act)
- Définir l'architecture d'hébergement avant de choisir le modèle, pas après
- Écrire la matrice d'accès en parallèle du développement, pas en post-livraison
- Intégrer les logs de décision dans le schéma de données dès le départ
- Nommer un responsable interne du système, pas juste un sponsor projet
Sur le projet Universal, un système de qualification de leads déployé en production, ce travail de cadrage gouvernance a retardé le démarrage du développement de deux semaines. Il a évité une remigration complète six mois plus tard quand les exigences RGPD ont été formalisées en interne. Deux semaines contre probablement huit : c'est le calcul.
L'IA gouvernée n'est pas un frein, c'est un accélérateur
C'est le point qui surprend toujours. On entend souvent que la conformité et la gouvernance ralentissent les projets IA. C'est vrai si on les ajoute après. C'est faux si elles sont intégrées dès la conception.
Un système IA qui répond aux exigences de traçabilité, d'hébergement et de contrôle des accès est un système qui :
- Obtient plus facilement le feu vert du RSSI et du DPO
- Se déploie sans blocage de dernière minute
- Reste en production sans être éteint au premier incident
- Peut évoluer sans tout reconstruire
Dans un environnement régulé, la gouvernance n'est pas ce qui empêche de livrer vite. C'est ce qui permet de livrer durablement.
Ce qu'il faut retenir
Le modèle est l'outil. L'environnement dans lequel il tourne est le produit. En grande entreprise, confondre les deux, c'est garantir soit un projet qui n'arrive jamais en production, soit un système qui y arrive mais ne survit pas au premier audit.
L'EU AI Act rend cette distinction obligatoire. Les entreprises qui l'anticipent maintenant ont 12 à 18 mois d'avance sur celles qui attendront les premières sanctions pour réagir.
Si vous ne savez pas précisément où en est votre niveau de conformité AI Act, c'est souvent la première chose à clarifier avant de lancer le prochain projet. Un état des lieux structuré de vos usages IA actuels, de votre architecture et de vos obligations réglementaires prend moins de temps que vous ne le pensez, et coûte infiniment moins que la découverte tardive d'un angle mort.