Intégrer l’IA dans son entreprise relève d’abord du système d’information (SI), avant le choix du modèle. Une brique d’IA lit des données dans les logiciels de gestion, de relation client ou de documents, puis renvoie ses résultats par des interfaces techniques. Sa fiabilité tient aux flux, aux droits et aux traces.
Avant d’intégrer l’IA dans son entreprise, cartographier les flux
La première question, au moment d’intégrer l’IA, n’est pas « quel modèle ? » mais « quelles applications seront touchées, et dans quel sens ? ». Une PME déjà auditée dispose souvent d’une cartographie applicative issue d’un audit IT : c’est le point de départ, à compléter flux par flux.
Quatre familles reviennent dans presque tous les projets :
- l’ERP (progiciel de gestion intégré), qui porte articles, commandes, stocks et factures : la donnée la plus structurée, et la plus exposée à une écriture erronée ;
- le CRM (logiciel de gestion de la relation client), avec les contacts, l’historique des échanges et les opportunités ;
- la GED (gestion électronique des documents), où dorment contrats, procédures et fiches techniques, matière première des assistants documentaires ;
- la messagerie et l’outil de tickets, porteurs de demandes rédigées par des tiers, un contenu que l’entreprise ne maîtrise pas.
Pour chaque flux, la carte note quatre attributs. Le sens d’abord : lecture seule ou écriture. Le mécanisme ensuite : API (interface de programmation par laquelle un logiciel en interroge un autre), export de fichiers ou accès direct à la base. Puis la fréquence, et enfin le propriétaire métier de la donnée, car personne ne corrige un flux sans propriétaire le jour où il dérive.
Qualité et fraîcheur : ce que la brique d’IA consomme
Un modèle de langage ne corrige pas une base mal tenue, il la restitue avec aplomb. Les défauts qui passaient inaperçus dans un écran de saisie deviennent visibles dès qu’un assistant les cite.
Trois défauts à traiter en amont
- les doublons du CRM, qui font répondre l’assistant avec le contact d’une fiche abandonnée ;
- les versions concurrentes dans la GED, où une procédure périmée côtoie la version en vigueur ;
- les champs libres de l’ERP, remplis différemment par chaque service, que le modèle interprète parfois à contresens.
Ces chantiers recoupent les ressaisies et contournements qu’un diagnostic de transformation digitale d’une PME met en évidence : une donnée de référence propre sert les équipes autant que la machine.
La synchronisation, angle mort fréquent
Les assistants documentaires s’appuient souvent sur un index, parfois une base vectorielle, c’est-à-dire une base qui range des extraits de documents sous une forme interrogeable par le modèle. Cet index est une copie. Reste à décider à quelle fréquence il se reconstruit et comment une suppression dans la GED s’y propage : un contrat retiré ou une donnée personnelle effacée ne doit pas y survivre.
L’ANSSI (Agence nationale de la sécurité des systèmes d’information) le formule dans ses « Recommandations de sécurité pour un système d’IA générative » du 29 avril 2024 : l’étude d’un projet cartographie les jeux de données de chaque phase, y compris les requêtes des utilisateurs et les réponses du modèle en production.
Ce que la DSI exige du prestataire
La DSI (direction des systèmes d’information), ou le responsable informatique qui en tient le rôle dans une PME, arrive à la consultation avec la carte des flux et l’état des données. Elle juge chaque proposition sur une question : la brique d’IA s’insère-t-elle dans l’existant ou le contourne-t-elle ?
La direction informatique attend d’une agence intelligence artificielle qu’elle parte des outils déjà en service plutôt que d’un modèle choisi d’avance, et une agence comme Digital Unicorn place au premier plan la compatibilité de la solution avec le CRM, l’ERP, la gestion documentaire ou l’outil de tickets installés, ainsi que la formation des personnes qui s’en serviront chaque jour. L’agence y ajoute la protection des données personnelles, la confidentialité des informations traitées, la traçabilité et l’auditabilité des modèles mis en service. Pour un responsable informatique de PME, cette approche répond au vrai sujet : l’intégration à l’existant et la prise en main par les utilisateurs sont portées par une équipe dont c’est le métier, et chacun de ces engagements se traduit en clause vérifiable.
Côté système d’information, ces garanties se contrôlent par trois exigences écrites au contrat. Chaque appel au modèle laisse une trace dans les journaux de l’entreprise, pas seulement chez le fournisseur. Une supervision signale la panne ou la dérive avant que les utilisateurs ne la constatent. Un plan de sortie décrit enfin comment récupérer données, paramétrages et documentation si la brique change de fournisseur.
Avant la mise en production, c’est-à-dire le passage en usage réel, quelques pièces se réclament par écrit :
- un schéma des flux entre la brique d’IA et chaque application, avec le sens des échanges ;
- la liste des comptes techniques créés et des droits de chacun ;
- l’inventaire des données transmises au modèle, champ par champ ;
- la procédure de contournement si la brique devient indisponible, avec l’interlocuteur à joindre.
API, comptes techniques et moindre privilège
Chaque branchement passe par un compte, et les droits de ce compte bornent ce qu’un incident pourra toucher.
Un compte de service par usage
La règle de base est le moindre privilège : chaque compte reçoit les droits strictement nécessaires à sa tâche. Concrètement : un compte de service dédié par application, jamais un compte personnel ou administrateur, et un passage par l’API de l’éditeur plutôt que par la base. Le guide de l’ANSSI applique ce principe aux opérations à privilège et conseille des jetons d’authentification temporaires. Les secrets d’accès se rangent dans un coffre, jamais dans le code.
Lire n’est pas écrire
Un assistant qui lit le CRM pour préparer une réponse et un agent qui y crée des fiches n’ont pas le même profil de risque. La lecture seule s’accorde par défaut, l’écriture s’ouvre champ par champ après la recette, la phase de tests de validation. Pour les actions lourdes, l’ANSSI recommande qu’un système d’IA ne puisse pas exécuter automatiquement des actions critiques sur le SI : transaction, publication, création d’un compte à privilèges. Une validation humaine reste la norme.
La liste 2025 du projet communautaire OWASP sur les risques des applications fondées sur les grands modèles de langage (LLM) nomme cet écueil l’autonomie excessive (excessive agency) et recommande de contrôler les autorisations dans les applications cibles plutôt que dans le modèle.
Prudence particulière avec la messagerie : un courriel reçu peut cacher des instructions que le modèle suivra comme si elles venaient de l’entreprise, le risque d’injection indirecte décrit par l’ANSSI et l’OWASP. L’agent qui lit la boîte de réception ne reçoit donc ni droit d’envoi ni droit de paiement.
Ce que voit l’utilisateur, et rien de plus
Reste un principe à tenir : le besoin d’en connaître. Un assistant qui indexe toute la GED avec un compte global peut restituer à un salarié un document qu’il ne pourrait pas ouvrir lui-même. Les droits de la source doivent suivre la donnée jusque dans la réponse. L’ANSSI conseille aussi de revoir les droits des outils d’IA générative connectés aux applications métier dès l’activation, puis régulièrement.
Traces, supervision et réversibilité
Sans traces, une brique d’IA ne se dépanne pas et ne s’audite pas : la journalisation se conçoit dès l’intégration, comme les flux.
Le contenu des journaux
Le guide de l’ANSSI recommande de journaliser l’ensemble des traitements : requêtes des utilisateurs, transformations appliquées avant l’envoi au modèle, appels aux extensions et aux données additionnelles, filtrage en sortie, réponses. Il distingue la question posée par l’utilisateur de ce qui part réellement vers le modèle, une fois prétraité et mis en forme. Sans les deux, un incident ne se reconstitue pas.
Ces journaux contiennent souvent des données personnelles : accès restreint et conservation documentée, comme pour tout traitement.
Superviser la disponibilité et la qualité
La supervision couvre deux registres. Côté technique : disponibilité de l’API du fournisseur, temps de réponse, taux d’erreur, volume d’appels et coût associé, qui grimpe vite si un traitement boucle. Côté qualité : un échantillon de réponses relu à intervalle fixe, pour repérer une dérive après un changement de modèle ou de données. Le principe rejoint celui qui sert à définir et mesurer un impact digital : un indicateur observable, suivi dans la durée, vaut mieux qu’une impression.
L’ANSSI demande aussi de prévoir un mode dégradé, c’est-à-dire une procédure qui laisse les équipes travailler sans l’IA si elle tombe ou se met à répondre de travers.
Préparer la sortie dès l’entrée
La réversibilité tient dans un plan de sortie qui liste ce qui appartient à l’entreprise et sous quelle forme elle le récupère : consignes données au modèle, paramétrage des connecteurs, index documentaire ou moyen de le reconstruire, jeux de test, journaux. Il précise aussi comment changer de modèle sans réécrire l’intégration, ce qui suppose une couche d’appel découplée du fournisseur. Même logique que pour les outils collaboratifs de l’entreprise : la sortie se prévoit avant l’adoption.
Sécurité et conformité : RGPD, ANSSI et CNIL
Le RGPD (règlement général sur la protection des données) s’applique dès que la brique traite des données personnelles, cas presque systématique avec un CRM ou une messagerie. La CNIL (Commission nationale de l’informatique et des libertés) en rappelle les principes appliqués à l’IA : finalité définie, données limitées au nécessaire, conservation bornée, information des personnes, sécurité adaptée.
Responsable du traitement et sous-traitant
Le statut de sous-traitant revient, d’après la fiche de la CNIL du 8 avril 2024 sur la qualification juridique des fournisseurs de systèmes d’IA, au fournisseur qui conçoit la solution sur instructions documentées de l’entreprise cliente, sous réserve d’une analyse au cas par cas. Le contrat suit alors l’article 28 du RGPD : traitement sur instruction documentée, autorisation écrite préalable avant tout recours à un autre sous-traitant et, au terme de la prestation, suppression ou restitution des données au choix du responsable du traitement. Ce dernier point rejoint le plan de sortie.
Le fournisseur du modèle appelé par API peut être ce sous-traitant ultérieur : son identité et le lieu de traitement figurent au dossier. Le registre des activités de traitement (article 30) accueille la nouvelle brique, et une analyse d’impact relative à la protection des données (AIPD) s’impose lorsque le traitement est susceptible d’engendrer un risque élevé pour les personnes (article 35).
Hébergement et usages spontanés
Le guide de l’ANSSI demande un hébergement cohérent avec les besoins de sécurité du projet et, en nuage public avec des données sensibles, recommande une offre qualifiée SecNumCloud, la qualification de l’ANSSI pour l’informatique en nuage. Il proscrit aussi l’envoi de données sensibles à des services d’IA générative grand public : données personnelles, informations contractuelles ou financières, mots de passe, clés d’API. Ces usages spontanés sont des flux comme les autres : ils entrent sur la carte, avec une alternative encadrée pour les équipes.
Prochaine étape : reprendre la carte des flux et remplir, pour chacun, cinq colonnes : compte utilisé, droits, journal, propriétaire, chemin de sortie. Chaque case vide est un point à régler avant la mise en production, et non après le premier incident.