Quand une direction métier arrive avec un projet d'IA branchée sur la base de production, la DSI se retrouve dans une position inconfortable. Dire non frontalement passe pour du blocage. Dire oui sans instruction expose le système d'information.
Cette checklist rassemble les points que nous instruisons systématiquement en cadrage. Elle est écrite pour être utilisée telle quelle en réunion, y compris face à un prestataire qui n'est pas nous.
1. Où la donnée est-elle lue, et où va-t-elle ensuite
Première question, et la plus discriminante. Deux architectures très différentes se cachent derrière la même promesse commerciale.
Soit la donnée est copiée dans un index ou un entrepôt intermédiaire, souvent chez un éditeur tiers. Il faut alors savoir où cet index est hébergé, comment il est chiffré, qui y accède, à quelle fréquence il est rafraîchi et comment il est purgé le jour où le contrat s'arrête.
Soit la donnée est lue à la source au moment de la question, sans duplication. C'est le principe d'un serveur MCP, et cela supprime d'un coup toute la série de questions précédentes.
À demander : un schéma d'architecture qui montre explicitement chaque endroit où la donnée transite et se pose.
2. Le service peut-il écrire dans les systèmes
La réponse par défaut doit être non, et elle doit être vérifiable autrement que par une déclaration.
À demander : le compte de connexion utilisé, ses droits réels sur la base, et la confirmation que ces droits sont en lecture seule au niveau du moteur, pas seulement dans la configuration applicative. Un droit d'écriture désactivé par une option logicielle reste un droit d'écriture.
Si l'écriture est prévue à terme, exiger qu'elle soit accordée périmètre par périmètre, avec une liste explicite des opérations autorisées, et pas un accès global qu'on restreindra plus tard.
3. Qui voit quoi, et où ce découpage est-il défini
Le point qui se néglige le plus, parce qu'il paraît résolu tant qu'on est en phase pilote avec cinq utilisateurs de confiance.
À demander : la matrice des rôles et des périmètres exposés, écrite avant la mise en service. Vérifier que le découpage est appliqué côté serveur, dans sa configuration, et non confié au modèle sous forme de consigne. Une instruction du type « ne montre pas les salaires » n'est pas un contrôle d'accès.
Vérifier aussi ce qui se passe pour un utilisateur sans rôle attribué. La bonne réponse est qu'il ne voit rien.
4. Que se passe-t-il si une question est mal posée
Une demande ambiguë sur une base volumineuse peut déclencher un balayage complet et dégrader la production pour tout le monde.
À demander : le plafond de volumétrie par requête, le délai maximal d'exécution, et surtout le fait que la lecture se fasse sur un réplica plutôt que sur l'instance de production quand l'architecture le permet.
5. Les données personnelles sont-elles traitées à part
Dès qu'un périmètre touche à des données RH, clients nominatives ou de santé, le sujet cesse d'être technique.
À demander : quels champs personnels sont exposés et pourquoi, quel seuil d'anonymisation s'applique sur les agrégats, et comment l'outil empêche de remonter à un individu par recoupement de plusieurs questions successives. Ce dernier point est le plus souvent oublié.
Prévoir l'association du DPO au cadrage, pas à la recette. Une architecture validée en fin de projet coûte cher à corriger.
6. Que reste-t-il comme trace
À demander : la journalisation des requêtes, avec auteur, horodatage et périmètre interrogé. Sa durée de rétention. Et qui peut la consulter.
Cette trace sert dans trois situations concrètes : un doute sur un chiffre présenté en comité, un contrôle d'accès à justifier, et une réclamation d'une personne concernée. Sans elle, aucune des trois n'a de réponse.
7. Où tourne le service, et sous quel contrat
À demander : la localisation d'hébergement du serveur, le fournisseur de modèle retenu, les conditions de rétention et de réutilisation appliquées par ce fournisseur aux contenus transmis, et si un mode sans rétention est disponible.
Vérifier également la réversibilité : le protocole étant ouvert, changer de modèle ne devrait pas imposer de tout reconstruire. Si le prestataire répond que son architecture est liée à un fournisseur unique, c'est une information à consigner.
8. Que devient le tout si le prestataire disparaît
À demander : sur quel dépôt le code est déposé, qui en est propriétaire, la documentation des vues exposées, et la procédure de reprise. Une couche d'accès à la donnée qui ne serait maintenable que par son auteur devient une dépendance critique en deux ans.
9. Comment vérifie-t-on que les réponses sont justes
Question rarement posée, et pourtant décisive. Un système qui renvoie des chiffres faux sans jamais lever d'erreur est plus dangereux qu'un système qui tombe.
À demander : la réponse indique-t-elle sur quelles vues elle a été construite, et un plan de recette existe-t-il qui confronte les premiers résultats à des chiffres déjà validés, état comptable ou tableau de bord existant.
C'est aussi le meilleur test de sérieux d'un prestataire. Ceux qui n'ont jamais mis ce type d'outil en production ne pensent pas à cette étape.
10. Le besoin justifie-t-il vraiment ce projet
La dernière question relève autant de la DSI que de la direction métier. Si les demandes portent sur cinq indicateurs stables consultés chaque semaine, un tableau de bord classique coûte moins cher et pose moins de questions.
L'approche prend son sens quand les questions ne sont pas connues d'avance et que leur variété rend impossible de toutes les prévoir. Faire écrire par le métier dix questions réelles restées sans réponse rapide tranche le débat plus vite qu'une réunion d'arbitrage.
Ce que cette checklist permet de dire
Utilisée en amont, elle permet à une DSI de ne pas être le service qui bloque, tout en restant celui qui instruit. Les dix points se répondent en une réunion avec un prestataire sérieux, et l'incapacité à répondre à trois d'entre eux est en soi une réponse.
Les garde-fous que nous appliquons sur chaque serveur livré, lecture seule par défaut, périmètre par rôle, volumétrie plafonnée, seuil d'anonymisation et journalisation, sont détaillés sur la page serveur MCP et interrogation des données en langage naturel. Et si la question de départ reste ouverte, un audit IA de quelques jours permet de trancher avant d'engager un budget de développement.
