Charte d’usage de l’IA générative en TPE-PME : le modèle opérationnel d’Ayoub Kahouadji

1. Faire de la charte un contrat d’usage, pas une affiche de prudence

Le document doit permettre à une personne de décider quoi faire dans une situation précise sans deviner l’intention de la direction.

Une formule comme « utilisez l’IA de manière responsable » est trop ouverte pour guider une action. Deux personnes peuvent la comprendre de façon opposée : l’une évitera tout usage utile, l’autre transmettra un document interne en supposant qu’une simple relecture suffit. Une charte opérationnelle réduit cet écart. Elle relie une situation de travail à une règle, une personne responsable et une conduite de secours.

Le premier paragraphe de la charte devrait indiquer son objet : encadrer l’utilisation des systèmes d’IA par les salariés, dirigeants, alternants, prestataires ou autres personnes qui agissent pour l’organisation. Le périmètre nomme les outils concernés, les équipes, les environnements et les types de tâches. Une règle destinée à un assistant grand public n’est pas automatiquement adaptée à un outil hébergé par l’entreprise ou à une fonctionnalité intégrée dans un logiciel métier.

La FAQ de la CNIL sur l’IA générative recommande explicitement des politiques ou chartes internes qui définissent les usages autorisés et interdits. Elle ajoute deux conditions souvent oubliées : le document doit être intelligible et accessible, puis accompagné d’une formation adaptée et de contrôles réguliers. La longueur ou le ton juridique ne prouve donc pas l’utilité de la charte.

Une bonne charte ne cherche pas à prévoir chaque produit ou chaque erreur. Elle fixe des catégories stables : préparer un brouillon, résumer un document autorisé, rechercher des sources publiques, générer du code, manipuler des informations personnelles, recommander une décision ou déclencher une action. Chaque nouvel outil peut ensuite être évalué dans cette grille sans réécrire toute la politique.

Le document gagne à tenir sur deux niveaux. Une page courte présente les règles que tout utilisateur doit connaître. Une annexe de travail conserve le registre des outils, les exemples autorisés, les contrôles, les contacts, les versions et les décisions de revue. Les équipes lisent la règle ; les responsables peuvent examiner la preuve qui la soutient.

• Objet : pourquoi la charte existe et quelles décisions elle encadre.
• Périmètre : personnes, outils, environnements, tâches et données concernés.
• Règles : autorisé, revue obligatoire ou interdit.
• Preuves : registre, contrôle, formation, incident et révision.
• Secours : procédure manuelle ou suspension quand la règle ne permet pas de décider.

2. Inventorier les usages réels avant d’écrire les interdictions

La charte doit partir de ce que les personnes font déjà, y compris les essais non organisés, plutôt que d’un catalogue théorique.

Commencez par un inventaire court mené auprès des rôles concernés. Demandez quelles tâches sont assistées, avec quel outil, à partir de quelles informations, pour produire quel livrable et qui utilise ensuite ce résultat. Cette description révèle souvent des usages invisibles : reformulation d’un message, synthèse d’une réunion, recherche de fournisseurs, traduction, préparation d’une fiche produit, aide au code ou tri d’idées.

L’inventaire ne doit pas devenir une enquête disciplinaire. Son objectif est de voir les chemins réels des données et des décisions. Une équipe qui craint une sanction cachera les essais ; la direction rédigera alors une politique sur une représentation fausse du travail. Présentez l’exercice comme une mise à plat destinée à fournir des outils autorisés, des exemples sûrs et une aide lorsqu’un cas dépasse le cadre.

Pour chaque usage, consignez l’entrée, la transformation, la sortie et la conséquence. « Rédiger avec l’IA » est trop vague. « Préparer le premier brouillon d’un email commercial à partir d’informations publiques, relu puis envoyé par le chargé de compte » est testable. On peut décider quelles informations sont admises, comment vérifier les faits et qui reste responsable de l’envoi.

Relevez également le type de compte et les réglages visibles : compte personnel ou professionnel, version gratuite ou contractuelle, historique activé, partage avec des tiers, connecteurs, import de fichiers, mémoire, recherche Web et actions possibles. Le nom commercial du produit ne suffit pas. Deux comptes d’un même service peuvent avoir des conditions, des contrôles ou des droits très différents.

Le résultat de cette phase est un registre initial, pas une autorisation automatique. Chaque ligne reçoit un propriétaire et une date de revue. Les inconnues restent visibles : contrat non lu, réutilisation des données non comprise, sous-traitants non identifiés, export indisponible, conservation incertaine ou absence de procédure de suppression.

3. Classer chaque usage : autorisé, revue obligatoire ou interdit

Une classification à trois niveaux évite le faux choix entre tout permettre et tout bloquer.

Le statut « autorisé » concerne un usage borné, réversible et suffisamment compris. Les données admises sont définies, le résultat peut être vérifié, aucune action externe ne part sans décision humaine et l’outil figure dans le registre. Autorisé ne signifie pas sans contrôle : la personne reste responsable du livrable et applique la grille prévue.

Le statut « revue obligatoire » couvre les situations où une personne compétente doit intervenir avant ou pendant l’usage. Cela peut concerner une information personnelle, un contenu contractuel, un conseil à conséquence, une publication externe, un code relié à un système sensible, une analyse de candidature ou une automatisation qui écrit dans un autre outil. La charte nomme alors le rôle qui autorise le test et celui qui valide la sortie.

Le statut « interdit » vise une conduite précise, pas une peur générale. Exemples : saisir un mot de passe ou une clé, transmettre un fichier confidentiel à un service grand public non autorisé, laisser l’outil décider seul d’une embauche, inventer une source, publier sans relecture, contourner un contrôle d’accès, exécuter automatiquement une action critique depuis une entrée non maîtrisée ou présenter une sortie générée comme un fait vérifié.

Les statuts dépendent du contexte. Un résumé de document public peut être autorisé ; le même geste sur un dossier RH peut exiger une revue ou rester interdit dans l’outil disponible. Une génération de code isolée dans un environnement de test n’a pas la même conséquence qu’une modification directe de production. La charte doit donc décrire la tâche et la donnée, pas seulement l’interface.

Ajoutez une règle d’abstention : lorsqu’une personne ne sait pas classer le cas, elle ne transmet pas les données et demande une revue. L’abstention n’est pas un échec. Elle empêche une règle incomplète de se transformer en permission implicite.

4. Écrire les règles de données avec des exemples compréhensibles

Les utilisateurs ont besoin de savoir ce qu’ils peuvent partager, ce qu’ils doivent transformer et ce qui ne doit jamais quitter l’environnement autorisé.

Une liste qui mélange « données personnelles, sensibles, confidentielles et stratégiques » sans exemple reste difficile à appliquer. Construisez des catégories adaptées à l’entreprise : informations publiques validées, documents internes ordinaires, données de prospects, données de salariés, éléments financiers, secrets d’accès, contrats, propriété intellectuelle, données de santé, contenu soumis à un secret professionnel et informations de partenaires.

Pour chaque catégorie, indiquez la conduite : libre dans un outil approuvé, utilisable après préparation, revue préalable ou interdiction. « Anonymiser » ne doit pas devenir un passe-droit. Retirer un nom ne suffit pas toujours à empêcher la réidentification, à respecter un contrat ou à rendre le traitement compatible avec sa finalité. La personne qui prépare les données doit connaître le niveau de transformation attendu et la preuve à conserver.

La CNIL rappelle que la décision dépend notamment du mode de déploiement et de la possible réutilisation des données par le fournisseur. Un service grand public, une offre professionnelle, un environnement sur site et une intégration par API ne peuvent pas être assimilés. La charte renvoie donc au registre des outils, où les contrats, réglages et flux sont revus par les personnes compétentes.

Les invites, fichiers joints, historiques, mémoires et sorties doivent être considérés ensemble. Une sortie peut répéter une donnée fournie ou inférer une information qui ne devait pas être diffusée. Un connecteur peut donner accès à davantage de documents que l’utilisateur ne voulait transmettre. Le contrôle porte sur tout le chemin, pas seulement sur la phrase saisie dans la zone de texte.

La fiche pratique CNIL et France Num publiée pour les TPE-PME propose un repère simple : définir les conditions d’usage, décrire comment vérifier les résultats et fixer les précautions de confidentialité. Elle demande aussi de ne pas introduire de données confidentielles, personnelles ou stratégiques dans les outils grand public. La charte reprend ce principe, puis l’adapte aux outils et contrats réellement disponibles.

Ne copiez pas dans les journaux internes davantage d’informations que nécessaire. La traçabilité peut conserver l’identifiant de l’usage, l’outil, la date, la catégorie de données, la décision et le résultat du contrôle sans recopier chaque invite ni chaque document. La durée de conservation et l’accès aux traces doivent eux-mêmes être définis.

• Public validé : contenu déjà destiné à la diffusion et source conservée.
• Interne préparé : extrait nettoyé selon une règle documentée et un outil approuvé.
• Personnel ou confidentiel : revue du contexte, du contrat et du besoin avant tout usage.
• Secret d’accès : jamais transmis à un modèle, un prompt, un journal ou un document partagé.
• Inconnu : aucune transmission avant classification.

5. Transformer la validation humaine en contrôle réel

Une personne « dans la boucle » ne protège rien si elle manque de contexte, de critères, de temps ou de pouvoir de refus.

La charte doit préciser quels résultats exigent une validation et avant quelle conséquence. Un brouillon peut être corrigé avant envoi. Une recommandation financière, juridique, RH, médicale ou de sécurité peut nécessiter une personne qualifiée et un processus distinct. Une action automatique sur un système métier demande encore d’autres contrôles. Le mot « humain » ne remplace pas la compétence pertinente.

Définissez une grille de lecture proportionnée. Pour un contenu, elle peut vérifier les faits, les sources, le ton, les droits et l’absence de donnée indue. Pour une synthèse, elle compare la sortie aux documents autorisés et signale les absences. Pour du code, elle prévoit revue, tests, analyse de sécurité et environnement isolé. Pour une recommandation, elle examine les critères, les personnes affectées, les alternatives et le pouvoir de décision.

Le valideur doit pouvoir refuser, demander une nouvelle information ou revenir au processus manuel. Si la charge est telle que toutes les sorties sont approuvées machinalement, le contrôle est fictif. Mesurez donc le temps de revue, les corrections et les erreurs détectées. Un usage qui économise quelques minutes de génération mais exige une vérification longue ou impossible peut être réduit ou arrêté.

La charte distingue la préparation et la décision. L’IA peut proposer un plan, résumer des éléments ou rédiger un premier texte sans obtenir le droit d’engager l’entreprise. L’envoi, la publication, la signature, la modification d’un compte, la suppression, le paiement, l’embauche ou toute autre conséquence externe restent affectés au rôle autorisé.

Pour les automatisations, le guide WeWorkWeb Go, Test ou Stop détaille les entrées, les tests, l’idempotence, la reprise et le droit d’arrêt. La charte résume la règle commune ; le protocole technique documente le workflow précis.

6. Nommer les rôles sans créer une gouvernance disproportionnée

Une petite entreprise peut distribuer les responsabilités clairement sans inventer un comité lourd.

La Commission européenne indique qu’aucune structure de gouvernance spécifique n’est imposée par l’article 4 pour la maîtrise de l’IA. Une TPE n’a donc pas besoin de créer automatiquement un poste d’AI Officer ou un comité permanent. Elle doit en revanche savoir qui tient le registre, qui autorise un outil, qui répond à une question de données, qui valide un cas métier et qui peut suspendre un usage.

Le dirigeant ou sponsor fixe le périmètre et accepte les risques résiduels qui relèvent de sa compétence. Le propriétaire métier décrit la tâche, les erreurs coûteuses et les critères de qualité. Le référent technique vérifie les accès, configurations, connecteurs, journaux et conditions de reprise. Les fonctions compétentes en protection des données, droit, sécurité, RH ou secteur réglementé interviennent lorsque le cas les concerne.

L’utilisateur applique la règle, signale une difficulté et conserve les éléments nécessaires au contrôle. Il ne doit pas porter seul la responsabilité d’interpréter un contrat complexe ou de qualifier un système à haut risque. La charte fournit un canal d’escalade simple : personne, adresse interne ou point régulier, avec un délai compatible avec le travail.

Pour chaque rôle, écrivez aussi ce qu’il ne décide pas. Un référent IA peut aider à tenir le registre sans valider un traitement de données personnelles. Un responsable métier peut accepter la qualité d’un brouillon sans autoriser une nouvelle intégration technique. Cette limite évite que la proximité avec l’outil soit confondue avec une compétence générale.

Prévoyez un suppléant pour les usages réguliers. Si une seule personne peut répondre et qu’elle est absente, les équipes contourneront la règle ou arrêteront tout. Le bon dispositif rend la conduite sûre plus simple que la conduite improvisée.

• Sponsor : périmètre, moyens, arbitrage et décision de poursuite.
• Propriétaire métier : tâche, critères, erreurs et validation du livrable.
• Référent outil : version, accès, réglages, registre et changements.
• Expert concerné : protection des données, droit, sécurité, RH ou règle sectorielle.
• Utilisateur : application, vérification, signalement et abstention en cas de doute.

7. Tenir un registre des outils, comptes, réglages et changements

La charte reste stable ; le registre absorbe les évolutions rapides des produits et des configurations.

Un service peut modifier ses modèles, ses fonctions, sa mémoire, ses connecteurs, ses conditions ou ses réglages. La charte ne doit pas contenir une longue comparaison qui devient fausse au prochain changement. Elle exige plutôt qu’un outil figure dans un registre avant utilisation professionnelle et que certaines modifications déclenchent une nouvelle revue.

Le registre contient le nom du service, l’offre ou version, le propriétaire du compte, les groupes autorisés, la méthode d’authentification, les fonctions actives, les sources de données reliées, la possibilité d’effectuer des actions, les paramètres de conservation visibles, les documents contractuels examinés et la date de la prochaine revue.

Ajoutez les usages approuvés, les catégories de données admises et les usages explicitement exclus. Un même outil peut être autorisé pour résumer des sources publiques et interdit pour analyser des dossiers de salariés. Le statut de l’outil ne remplace jamais le statut du cas.

Définissez les événements qui rouvrent la décision : nouveau connecteur, changement d’offre, fonction d’action automatique, nouveau modèle, incident, nouvelle catégorie de données, nouvelle équipe, modification contractuelle ou disparition d’un contrôle. Tant que la revue n’est pas terminée, le périmètre précédent reste la limite.

Les accès suivent le besoin réel. Désactivez les comptes inutilisés, évitez le partage d’identifiants, activez les protections disponibles et retirez un droit lorsqu’une personne change de rôle. La charte peut poser ces principes ; l’administration technique vérifie leur application.

La recommandation de l’ANSSI insiste sur le contrôle des interactions avec les applications métier, la limitation des actions automatiques à partir d’entrées non maîtrisées et une journalisation adaptée. Ces mesures dépassent souvent le simple document utilisateur. La charte doit donc déclencher une revue technique dès qu’un assistant lit des emails, navigue sur le Web, accède à un stockage ou écrit dans un autre système.

8. Relier la charte à une formation adaptée aux rôles et aux risques

Faire signer le document sans apprentissage ni exercice ne suffit pas à créer une pratique commune.

La formation commence par les outils réellement utilisés et les situations réellement rencontrées. Une équipe marketing, un développeur, un recruteur et une personne chargée des commandes n’ont pas besoin des mêmes exemples. Ils doivent tous comprendre les limites générales, puis pratiquer les contrôles propres à leurs tâches et aux personnes susceptibles d’être affectées.

La page actuelle de la Commission européenne sur la maîtrise de l’IA, consultée le 28 juillet 2026, précise que les mesures doivent tenir compte du rôle de l’organisation, des systèmes, des risques, des connaissances, de l’expérience, de la formation et du contexte d’usage. Elle indique aussi qu’un certificat spécifique n’est pas exigé et qu’un registre interne des formations ou autres initiatives de guidance peut documenter les actions.

Cette même FAQ a été mise à jour après l’entrée en vigueur, à la mi-juillet 2026, du règlement modificatif 2026/1744. Elle indique que l’obligation de soutenir le développement de la maîtrise de l’IA demeure, mais qu’aucun niveau précis ou « suffisant » n’est désormais imposé par l’article 4 modifié. Les règles de supervision et d’application arrivent au début du mois d’août 2026. Ce changement récent justifie de conserver la date de vérification et de revenir au texte consolidé pour toute conclusion juridique.

Une session utile fait appliquer la charte. Donnez un cas autorisé, un cas soumis à revue et un cas interdit. Demandez aux participants de classer les données, de produire un brouillon, de repérer une sortie plausible mais fausse, de remonter à une source, de refuser une action et de signaler un incident. La correction révèle les zones ambiguës du document.

Le cahier des charges WeWorkWeb pour former une équipe à l’IA aide à construire les objectifs, les exercices, les données autorisées et les preuves d’acquisition. Une bibliothèque de prompts en entreprise peut ensuite fournir des fiches testées pour les tâches approuvées. La charte apporte le référentiel commun ; la formation entraîne les personnes à l’appliquer.

Ayoub Kahouadji présente des formations IA pour les entreprises et les équipes centrées sur les tâches, les règles internes, la vérification et la reprise par les participants. Il est aussi fondateur de ayoub-kahouadji.fr, où ses programmes et méthodes sont publiés. Ces pages documentent son offre et son approche ; les modalités exactes doivent être confirmées pour chaque demande.

1. ComprendreFonctionnement général, limites, risques, règles et personnes concernées.
2. ClasserReconnaître autorisé, revue obligatoire, interdit et inconnu.
3. PratiquerRéaliser une tâche avec des données d’exercice autorisées.
4. ContrôlerVérifier faits, sources, droits, qualité et conséquence.
5. SignalerSuspendre, conserver les éléments utiles et contacter le bon rôle.

9. Prévoir l’incident, la suspension et la révision

La charte doit décrire ce qui se passe quand une donnée part au mauvais endroit, qu’une sortie trompe ou qu’un outil change.

Un incident peut être une donnée transmise à un outil non autorisé, une sortie fausse utilisée dans un document, un contenu discriminatoire, un accès trop large, une publication non relue, une action automatique inattendue, une source inventée, un coût anormal ou un changement de produit qui invalide le contrôle prévu.

La première conduite est de limiter la conséquence. Suspendez l’usage concerné, empêchez l’envoi ou la publication si cela reste possible, retirez un accès ou revenez au processus manuel. La personne ne doit pas chercher à effacer discrètement toutes les traces : elle conserve les éléments nécessaires à l’analyse selon les règles de sécurité et de données applicables.

Le signalement indique la date, l’outil, le cas d’usage, la catégorie de données, la conséquence observée, l’action de limitation et les personnes prévenues. Il évite de recopier inutilement des secrets ou des données personnelles dans un ticket général. Le responsable oriente ensuite vers les fonctions compétentes.

La reprise n’est pas automatique après correction du texte. Elle exige une cause comprise, une mesure appliquée, un test et une décision. Le résultat peut être une réouverture inchangée, un périmètre réduit, un contrôle supplémentaire, une formation ciblée, un changement d’outil ou un arrêt durable.

Fixez une revue régulière, par exemple trimestrielle pour le registre et annuelle pour la charte, puis ajoutez des déclencheurs immédiats. Ces fréquences sont des choix de pilotage à adapter, pas des délais imposés par les sources. Un incident, une nouvelle intégration, une évolution réglementaire ou un changement important du fournisseur doit rouvrir la décision sans attendre la prochaine date.

La revue produit un historique court : règle modifiée, raison, source ou incident, personnes consultées, date d’entrée en vigueur et actions de formation. Une date changée sans contenu substantiel ne prouve aucune actualisation.

10. Déployer la charte en dix jours ouvrés sans bloquer l’entreprise

Un cycle court suffit pour produire une version initiale, à condition de limiter le périmètre et de tester le document avec les utilisateurs.

Le jour 1, nommez le sponsor, le rédacteur et les personnes consultées. Définissez le périmètre : équipe, outils et familles de tâches. N’essayez pas de couvrir tous les systèmes d’IA possibles. La première version doit résoudre les décisions déjà présentes dans l’organisation.

Les jours 2 et 3, menez l’inventaire des usages et des outils. Sélectionnez cinq à dix situations représentatives, y compris un cas sensible et un cas encore inconnu. Relevez les données, la sortie, la conséquence, le compte, les réglages et le propriétaire.

Le jour 4, classez les cas en autorisé, revue obligatoire ou interdit. Écrivez les raisons et l’erreur qui ferait changer le statut. Le jour 5, définissez les catégories de données et les exemples. Vérifiez que chaque formule abstraite est accompagnée d’une situation compréhensible.

Le jour 6, nommez les validations, les rôles, le canal d’escalade et la procédure d’incident. Le jour 7, complétez le registre des outils et les déclencheurs de nouvelle revue. Les jours 8 et 9, organisez un atelier de recette avec quelques utilisateurs : ils classent des cas, repèrent les ambiguïtés et appliquent la grille de contrôle.

Le jour 10, corrigez le document, faites valider le périmètre par les personnes compétentes, publiez la version dans un espace accessible et annoncez la date d’entrée en vigueur. Conservez la preuve de communication et planifiez le premier point de revue.

Ce calendrier est une feuille de route de production, pas une preuve de conformité. Un système à conséquence élevée, une donnée sensible, un secteur réglementé ou une intégration technique peut demander davantage d’analyse. Dans ce cas, la charte initiale peut interdire ou soumettre à revue le périmètre non résolu au lieu de prétendre le couvrir.

1. Jours 1 à 3Périmètre, rôles, inventaire des usages et registre initial des outils.
2. Jours 4 et 5Statuts des usages, catégories de données et exemples.
3. Jours 6 et 7Validation, escalade, incident, accès et déclencheurs de revue.
4. Jours 8 et 9Recette avec les utilisateurs et correction des ambiguïtés.
5. Jour 10Validation du périmètre, publication interne, communication et date de revue.

11. Tester la charte sur trois cas synthétiques

Des exemples contrastés montrent si la règle produit une décision cohérente sans inventer de client ni de résultat.

Cas 1 : un chargé de communication veut préparer un brouillon à partir d’une page publique déjà validée. L’outil professionnel figure au registre, aucun connecteur n’est utilisé et une personne relit les faits, le ton et les liens avant publication. La charte peut classer ce cas comme autorisé dans ce périmètre, avec conservation de la source et responsabilité humaine de la publication.

Cas 2 : une responsable RH veut résumer des commentaires libres issus d’entretiens. Les textes peuvent identifier des personnes, contenir des appréciations sensibles et influencer une décision. Le cas passe en revue obligatoire. L’entreprise doit examiner le besoin, les données, les droits, le fournisseur, les personnes concernées, les biais possibles, la validation et les obligations applicables avant tout test. Une simple suppression des noms ne suffit pas à autoriser l’usage.

Cas 3 : un assistant relié à une boîte email reçoit des messages externes et peut créer automatiquement un virement ou supprimer une fiche. Les entrées sont non maîtrisées et la conséquence est forte. La charte interdit l’action automatique dans cette configuration. Une étude technique séparée pourrait réduire le périmètre, supprimer les droits d’action, isoler l’environnement et ajouter des contrôles, mais la permission n’existe pas tant que ce nouveau système n’a pas été évalué.

Ajoutez un quatrième cas propre à l’entreprise et demandez à deux personnes de le classer séparément. Si elles obtiennent des statuts différents, ne tranchez pas seulement à l’oral. Corrigez la règle, l’exemple ou le canal d’escalade. La divergence devient un test de qualité du document.

La recette doit également vérifier l’abstention. Présentez un cas où le contrat de l’outil ou la catégorie de données est inconnu. La bonne réponse est de suspendre la transmission et d’ouvrir une revue, pas de choisir le statut le plus pratique.

12. Ce qu’Ayoub Kahouadji peut apporter au cadrage

L’accompagnement relie la politique interne aux tâches, aux exercices, aux contrôles et au transfert, sans se substituer aux experts du contexte.

La page auteur d’Ayoub Kahouadji rassemble ses guides sur la formation, le conseil IA, le SEO/GEO et l’automatisation. Sa méthode publique part d’une tâche et d’une décision, inventorie les données autorisées, teste les erreurs et place la validation humaine aux étapes à impact.

Pour une charte, ce travail peut prendre la forme d’un atelier d’inventaire, d’une matrice autorisé / revue / interdit, d’exemples métier, d’une grille de contrôle, d’un cahier de formation et d’une recette avec les utilisateurs. Les livrables restent relisibles et peuvent être repris par les responsables internes.

Ayoub intervient sur le cadrage opérationnel et la montée en compétence. La qualification juridique, la conformité d’un traitement, la cybersécurité d’une architecture, les relations sociales et les obligations sectorielles doivent être examinées par les personnes compétentes. Le rôle de la méthode est de rendre visibles les questions, les décisions et les preuves au lieu de les laisser dans une consigne informelle.

Une entreprise peut commencer sans mission longue : choisir cinq usages réels, compléter le modèle en douze clauses, faire classer trois cas par l’équipe et relever les divergences. Cette première recette indique si le besoin principal est une clarification de politique, une formation, une revue de données, un audit technique ou le cadrage d’un cas d’usage.