IA locale et gouvernance des données : comment choisir la bonne architecture
Lors de la première vague d’expérimentation, de nombreuses entreprises ont abordé l’IA comme une question presque exclusivement d’application : quel outil utiliser, quel fournisseur choisir, quelles personnes impliquer pour démarrer rapidement. C'était une phase nécessaire. Mais lorsque l’usage se rapproche des processus réels, la question change de nature. Il ne suffit plus de se demander si l’IA peut être utile. Nous devons comprendre où cela doit se dérouler, avec quelles données, avec quelles frontières, sous quels contrôles et avec quelle traçabilité.
C’est à cette étape que la gouvernance des données cesse d’être un chapitre juridique ou informatique en aval du projet et devient un choix de conception.
En Europe l’enjeu est désormais explicite : l’AI Act est entré en vigueur en août 2024 ; Les interdictions, définitions et obligations en matière de maîtrise de l’IA s’appliquent depuis février 2025, tandis que les règles et obligations de gouvernance pour les modèles à usage général sont entrées en application depuis août 2025.
Le NIST, avec le profil dédié à l'IA générative, insiste sur le fait que le risque doit être géré tout au long du cycle de vie, de la conception au suivi. Traduit en termes commerciaux : l’architecture et la gouvernance ne peuvent plus être séparées.
L’IA locale n’est pas une idéologie : c’est une option architecturale
Dans le débat public, l’idée d’une IA locale est souvent lue comme une réaction défensive : peur du cloud, méfiance à l’égard des grands fournisseurs, volonté de contrôle total. En réalité, il s’agit plus simplement d’une des options de conception disponibles. Exécuter un modèle localement, sur des appareils ou dans des environnements privés, peut avoir beaucoup de sens lorsque des données sensibles, des besoins de latence, une continuité opérationnelle dans des contextes hors ligne, des contraintes réglementaires ou la nécessité de réduire l'exposition des flux d'informations entrent en jeu.
Microsoft a mis en évidence des scénarios dans lesquels le traitement local permet de traiter des données sensibles sans les télécharger dans le cloud, tandis que Deloitte prédit une croissance significative des appareils équipés de capacités d'IA générative locale. Cela signifie que l’IA locale n’est plus un sujet de laboratoire. Cela fait désormais partie de la stratégie d’entreprise en matière d’appareils, de sécurité et de productivité.
Trois architectures, trois logiques de valeurs
Pour simplifier, les entreprises peuvent aujourd’hui réfléchir à trois modèles.
Le premier est on-device ou local-first, utile pour les tâches personnelles ou d'équipe qui nécessitent une proximité avec les données, une rapidité de réponse, un fonctionnement même sans connexion ou une réduction du risque d'exposition.
Le second est l’environnement privé ou sur site, plus adapté lorsqu’un contrôle strict, une intégration approfondie avec les systèmes internes, une auditabilité et des politiques strictes d’accès aux données sont nécessaires.
Le troisième est le modèle hybride, qui pour de nombreuses entreprises est le plus réaliste : une partie du travail reste proche des données, une autre profite de l'évolutivité, de la mise à jour et de la puissance du cloud.
Il ne s’agit pas de décider dans l’abstrait si le local ou le cloud est préférable. L’essentiel est de comprendre quel segment du flux de travail doit rester proche des données et lequel, à la place, peut bénéficier d’une capacité externe plus large. Penser en termes binaires conduit presque toujours à deux erreurs opposées : des systèmes surprotégés mais inutilisables, ou des systèmes très accessibles mais trop exposés et mal gouvernables.
Les cinq choix de conception qui comptent vraiment
Il existe au moins cinq décisions architecturales vraiment importantes.
La première concerne la classification des données : quelles données sont autorisées, sensibles, confidentielles, interdites ou soumises à des conditions particulières.
La seconde concerne le mouvement des données : où elles entrent, où elles sont traitées, si elles sont stockées, pour combien de temps et avec quelle logique de conservation.
Le troisième concerne le modèle : taille, coût, latence, capacité de personnalisation, explicabilité et contraintes de déploiement.
Le quatrième concerne les contrôles et les responsabilités : identité, journalisation, approbations humaines, traçabilité des accès, gestion des exceptions.
Le cinquième concerne l'intégration avec les bases de connaissances et les systèmes de dossiers d'entreprise.
Sans ces choix, la gouvernance reste un document et non un système d'exploitation. Et lorsque la gouvernance ne se traduit pas par des décisions de conception, elle est presque inévitablement contournée par les entreprises.
Parce que les modèles plus grands ne sont pas toujours le meilleur choix
Dans le discours public, il existe encore une fascination presque automatique pour les modèles plus grands. Mais dans le contexte des entreprises, la taille ne coïncide pas toujours avec la valeur. IBM note que les PDG peuvent obtenir un avantage plus concret en adoptant des modèles plus petits, alimentés par des données commerciales pertinentes, car dans de nombreux cas, ils produisent des résultats plus adaptés au contexte, avec un coût de calcul inférieur et une plus grande contrôlabilité. C’est un point clé : la qualité perçue en entreprise dépend souvent davantage de l’alignement du domaine que de la seule puissance générique du modèle.
De plus, les modèles locaux ou plus compacts obligent souvent l’organisation à être plus disciplinée. Ils permettent de limiter les cas d’usage, de mieux sélectionner les données, de définir des résultats plus mesurables, de distinguer ce qui doit rester interne de ce qui peut être délégué en externe. Dans de nombreux cas, cette discipline améliore non seulement la sécurité, mais aussi l'adoption.
Gouverner les données, c’est gouverner le comportement
La gouvernance des données dans l’IA ne se limite pas à une politique. Cela touche aux comportements quotidiens : ce qui peut être copié et collé dans un système, quels connecteurs sont autorisés, comment une base RAG est construite, quelles sorties doivent être vérifiées, ce qui doit être enregistré, ce qui peut être réutilisé pour un réglage fin, quels droits le fournisseur a sur les entrées et les sorties, comment l'anonymisation et la conservation sont gérées.
L'EDPB a attiré l'attention sur les risques de confidentialité et de fuite associés aux grands modèles linguistiques, soulignant que l'utilisation de ces systèmes nécessite des mesures techniques et organisationnelles cohérentes.
Cela signifie qu’une gouvernance efficace ne se limite pas au service juridique. C'est celui qui s'étend au comportement de l'utilisateur individuel et du gestionnaire individuel. Si les utilisateurs ne savent pas quelles données ils peuvent utiliser, où vont les journaux, quand un examen humain est nécessaire ou quelles sources sont approuvées, l'architecture sera rapidement contournée.
Le meilleur choix est celui que l’entreprise parvient à adopter
Dans de nombreuses organisations, le problème n’est pas de choisir l’architecture la plus sophistiquée, mais la plus adoptable. On évitera une plateforme parfaitement sécurisée mais trop lente, trop complexe ou trop éloignée du travail réel. Une solution très simple mais sans contrôle des données ni traçabilité générera au contraire de la peur, des résistances et, tôt ou tard, des accidents. La véritable adoption se situe entre les deux : une confiance suffisante, des frictions acceptables, une clarté sur les rôles et les responsabilités.
C’est pourquoi l’IA locale, les architectures hybrides et la gouvernance des données ne sont pas des sujets techniques à laisser aux spécialistes. Il s’agit de choix de modèles de gestion et d’exploitation. Ils déterminent quels cas d'utilisation peuvent évoluer, dans quelle mesure l'entreprise leur fait confiance, quelle liberté l'équipe peut avoir et dans quelle mesure l'organisation peut transformer l'expérimentation en un système stable.
La vraie question n’est pas seulement de savoir où fonctionne le modèle. Il s’agit de savoir si ce choix rendra l’IA enfin utilisable, contrôlable et durable pour l’entreprise.
Points à retenir
- À mesure que l’IA entre dans les processus, l’architecture et la gouvernance des données font partie de la stratégie d’adoption.
- L'IA locale, les environnements privés et les modèles hybrides répondent à différents besoins en matière de risque, de latence, de souveraineté et de convivialité.
- Les décisions clés impliquent la classification des données, le mouvement des données, le choix du modèle, les contrôles et l'intégration.
- Une gouvernance efficace ne se limite pas aux politiques : elle s’étend au comportement quotidien des utilisateurs, des gestionnaires et des systèmes.
