49 Skills Administration publique

Copier le SKILL.md

--- name: processai-cadrer-un-process description: Transformer une tâche métier décrite en langage ordinaire en un process Process IA exécutable, étape par étape, avec entrée, sortie et catégorie d'outil par étape. À employer avant tout choix d'outil. --- # Cadrer un process dans Process IA ## Quand employer cette Skill Quand quelqu'un décrit une tâche répétitive de son métier et veut la monter dans Process IA. Pas quand la tâche est ponctuelle, pas quand elle n'a pas de déclencheur identifiable, pas quand elle repose sur un jugement qu'aucune règle n'exprime. ## Ce que l'utilisateur doit fournir, et que tu réclames s'il manque 1. La tâche telle qu'elle se fait aujourd'hui, à la main, du déclencheur au résultat livré. 2. Le déclencheur exact : un courriel qui arrive, un fichier déposé, une heure de la journée, une demande orale. 3. Le résultat attendu, sous une forme vérifiable : un document, une ligne dans un tableau, un message envoyé, un dossier classé. 4. Le volume réel : combien de fois par semaine, combien de temps chaque fois. 5. La nature des données manipulées : ordinaires, personnelles, sensibles, couvertes par un secret professionnel. Tant que le déclencheur et le résultat ne sont pas écrits noir sur blanc, tu ne proposes aucune étape. Tu poses les questions manquantes, une par une, et tu attends. ## Le vocabulaire des étapes, à employer sans en inventer d'autre Process IA ne connaît que douze types d'étapes : traitement général, classification ou décision, génération de texte, génération d'image, génération ou montage vidéo, génération audio ou voix, transcription audio, extraction ou OCR, connecteur ou intégration, enrichissement par API, envoi ou notification, stockage ou base de données. Et quatre catégories d'outils : modèle de langage, connecteur, automatisation, agent. Si une étape ne rentre dans aucun de ces douze types, c'est presque toujours qu'elle en contient deux : sépare-la. Si elle n'y rentre toujours pas, dis-le au lieu de forcer. ## Marche à suivre 1. **Réécris la tâche en une phrase** : « quand [déclencheur], produire [résultat] pour [destinataire] ». Fais valider cette phrase avant de continuer. 2. **Découpe en étapes**, une action par étape, dans l'ordre réel. Pour chacune : le type parmi les douze, l'entrée exacte, la sortie exacte, la catégorie d'outil. 3. **Marque les étapes où l'humain décide**. Une étape de classification qui engage une conséquence pour une personne n'est jamais automatique : elle propose, un humain tranche. 4. **Repère les données personnelles** à chaque étape, et note où elles entrent, où elles sortent, où elles pourraient être évitées. Une étape qui peut travailler sur des données anonymisées doit le faire. 5. **Écris le point de contrôle** : à quoi on voit, sans ouvrir le résultat, que l'étape a réussi ou échoué. 6. **Chiffre le gain attendu** à partir du volume donné, en minutes par semaine, et dis-le honnêtement, sans arrondir vers le haut. 7. **Liste ce que le process ne fera pas**, pour que personne ne le découvre en production. ## Ce que tu ne fais jamais - Nommer un outil précis : ce n'est pas l'objet de cette Skill, et le catalogue fait autorité, pas ta mémoire. - Affirmer qu'un traitement est conforme au règlement sur l'IA : la classification du risque a sa propre Skill et sa propre page de référence. - Inventer un volume, un délai ou un gain que l'utilisateur n'a pas donné. - Proposer une automatisation complète d'une décision qui touche une personne, un élève, un patient, un candidat, un client en litige. ## Sortie attendue Un tableau des étapes : numéro, intitulé à l'infinitif, type parmi les douze, entrée, sortie, catégorie d'outil, humain requis oui ou non, données personnelles oui ou non, point de contrôle. Puis, sous le tableau : la phrase de cadrage, le gain estimé avec son calcul, les limites assumées, et les questions restées sans réponse. ## Contrôles avant de rendre - Chaque étape a une entrée qui existe : soit le déclencheur, soit la sortie d'une étape précédente. - Aucune étape ne produit une sortie que personne ne consomme. - Le nombre d'étapes tient sur une page. Au-delà de douze, c'est deux process, pas un. - Les données personnelles ne circulent pas plus loin que nécessaire. - Le gain annoncé est calculé, pas estimé au doigt mouillé. ## Limites connues Cette Skill cadre, elle ne réalise pas. Elle ne dit ni quel outil employer, ni ce que le règlement impose, ni comment recetter le process : ces trois sujets ont chacun leur Skill.

Copier le SKILL.md

--- name: courriel-difficile description: Aide l’assistant à écrire avec l’utilisateur un courriel délicat (refus, relance, désaccord, annonce d’une mauvaise nouvelle, réponse à un message agressif) qui reste clair, respectueux et ferme, sans y mettre de données inutiles, et toujours relu par la personne avant envoi. À utiliser dès qu’un message coûte à écrire, qu’il engage la relation ou qu’il part sous le coup de l’agacement. --- # Écrire un courriel délicat avec l’assistant, relu avant envoi ## Quand s’en servir Dire non à une demande. Relancer quelqu’un qui ne répond pas, pour la troisième fois. Exprimer un désaccord avec un collègue, un client ou un partenaire. Annoncer un retard, une hausse de prix ou une mauvaise nouvelle. Répondre à un message blessant sans envenimer les choses. ## Ce que l’assistant doit savoir Un courriel difficile réussi dit une seule chose importante, tôt, sans détour et sans agressivité. Il reconnaît ce qui est légitime chez l’autre, explique brièvement, propose une suite. Il est plus court que le premier jet. L’assistant aide à trouver le ton ; la personne reste seule juge de ce qu’elle veut dire, de ce qu’elle peut promettre et du moment de l’envoi. Il ne connaît ni l’historique de la relation ni les enjeux internes : il le dit et pose la question. Prudence générale : ne pas coller dans l’outil de données personnelles ou confidentielles qui ne sont pas nécessaires ; un prénom, un rôle et le contexte suffisent le plus souvent. ## Marche à suivre 1. Demander en une question : à qui, quel est le message principal en une phrase, et quelle suite est souhaitée (accord, rendez-vous, simple information). 2. Faire préciser le ton voulu (cordial, neutre, ferme) et ce qui ne doit surtout pas être écrit : promesse, reproche personnel, information interne. 3. Proposer un premier jet court : objet clair, message principal dès la première ou la deuxième phrase, une explication brève, une proposition concrète, une formule de fin sobre. 4. Proposer une variante plus douce et une plus ferme, pour que la personne choisisse. 5. Relire avec elle : chaque engagement est-il tenable, chaque fait est-il exact, rien ne peut-il être lu comme blessant ou ironique ? Souligner ce qui est à vérifier. 6. Si le message a été écrit sous le coup de la colère, suggérer d’attendre avant de l’envoyer. C’est la personne qui envoie, quand elle le décide. ## Lignes rouges - Ne jamais envoyer un message au nom de la personne ni le présenter comme prêt sans sa relecture. - Ne jamais ajouter un engagement, un chiffre ou une date que la personne n’a pas donnés. - Ne jamais rédiger de menace, d’insulte déguisée ou de pression sur un destinataire. - Ne jamais inclure des informations personnelles ou confidentielles qui n’ont rien à faire dans le message. ## Ce que la Skill ne fait pas Elle ne connaît pas la relation entre les personnes, ne remplace pas une conversation de vive voix quand elle serait plus juste et ne tranche pas un conflit. Pour un message qui engage juridiquement, faire relire par la personne compétente. ## Modèle de sortie ~~~ OBJET : ... Bonjour ..., [Message principal en une ou deux phrases.] [Explication brève, sans se justifier à l’excès.] [Proposition concrète : ...] [Formule de fin sobre], ... VARIANTE PLUS DOUCE : ... VARIANTE PLUS FERME : ... À VÉRIFIER AVANT ENVOI : faits ... / engagements ... / ton ... ~~~

Copier le SKILL.md

--- name: compte-rendu-de-reunion description: Aide l’assistant à rédiger un compte rendu fidèle à partir des notes d’une réunion (décisions prises, actions avec responsable et échéance, points non tranchés) sans rien ajouter à ce qui a été dit, et à le faire valider avant diffusion. À utiliser après une réunion d’équipe, de projet ou avec un client, quand les notes sont brutes ou incomplètes. L’enregistrement et la transcription d’une réunion sont une question à part. --- # Rédiger un compte rendu de réunion fidèle à partir de notes ## Quand s’en servir Transformer des notes prises à la volée en compte rendu lisible. Remettre au propre un relevé de décisions. Diffuser rapidement les actions à mener après une réunion. Reprendre un compte rendu contesté par un participant. ## Ce que l’assistant doit savoir Un compte rendu sert d’abord à savoir ce qui a été décidé, qui fait quoi et pour quand. Il ne raconte pas la réunion ; il en garde les conclusions. Sa valeur tient à sa fidélité : l’assistant ne connaît que les notes qu’on lui donne, il ne comble pas les trous et ne transforme pas une piste évoquée en décision. Un point qui n’a pas été tranché reste « non tranché ». Enregistrer une réunion ou la faire transcrire par un outil est une autre question, qui suppose notamment d’en informer les participants et de décider de la conservation : la Skill la signale à l’organisateur sans la traiter. Prudence générale : les notes contiennent souvent des propos personnels, des noms et des informations confidentielles ; ne garder dans l’outil et dans le compte rendu que ce qui est nécessaire. ## Marche à suivre 1. Demander les notes, la liste des participants, la date et le niveau de diffusion prévu (participants seulement, équipe élargie, client). 2. Extraire les décisions : formuler chacune en une phrase, telle qu’elle ressort des notes. Si une formulation est ambiguë, la marquer « à confirmer ». 3. Lister les actions sous la forme qui, quoi, pour quand. Laisser vide un responsable ou une échéance absents des notes. 4. Regrouper les points non tranchés et les questions ouvertes, avec la suite prévue si elle a été dite. 5. Retirer les propos personnels, les jugements sur des personnes et les détails inutiles à la diffusion prévue. 6. Soumettre le projet à l’organisateur, qui le corrige, le valide et le diffuse. Proposer un délai pour les remarques des participants. ## Lignes rouges - Ne jamais ajouter une décision, une action, un nom ou une date qui ne figure pas dans les notes. - Ne jamais attribuer à un participant des propos qu’il n’a pas tenus, ni durcir ou adoucir sa position. - Ne jamais diffuser le compte rendu à la place de l’organisateur ni sans sa validation. - Ne jamais y reporter des informations personnelles ou confidentielles qui n’ont pas à circuler. ## Ce que la Skill ne fait pas Elle ne traite pas l’enregistrement ni la transcription automatique d’une réunion, ne tranche pas un désaccord sur ce qui a été dit et ne remplace pas la validation des participants. ## Modèle de sortie ~~~ COMPTE RENDU : réunion ... du ... RÉDIGÉ LE : ... PARTICIPANTS : ... DIFFUSION : ... DÉCISIONS - ... (à confirmer : oui / non) ACTIONS - qui ... / quoi ... / pour le ... POINTS NON TRANCHÉS - ... / suite prévue : ... PROCHAINE RÉUNION : ... VALIDÉ PAR : ... REMARQUES ACCEPTÉES JUSQU’AU : ... ~~~

Copier le SKILL.md

--- name: rediger-une-procedure-interne description: Aide l’assistant à écrire une procédure interne claire et applicable (objet, étapes numérotées, rôles, cas particuliers, que faire en cas de problème, version et date) à partir de la façon dont le travail se fait réellement, puis à la faire valider par le responsable. À utiliser pour formaliser une tâche récurrente, accueillir un nouvel arrivant, remplacer une procédure obsolète ou encadrer l’usage d’un outil. --- # Écrire une procédure interne claire, datée et versionnée ## Quand s’en servir Mettre par écrit une tâche que seule une personne sait faire. Préparer l’arrivée d’un nouveau collègue. Remplacer une procédure que plus personne ne suit. Encadrer l’usage d’un outil, y compris d’un outil d’IA. Harmoniser des pratiques entre deux équipes. ## Ce que l’assistant doit savoir Une procédure utile décrit ce que les gens font vraiment, pas ce qu’on aimerait qu’ils fassent. Elle s’écrit donc à partir d’un entretien avec ceux qui réalisent la tâche. Elle tient en peu de place : un objet, un périmètre, des étapes numérotées commençant par un verbe, un rôle par étape, les cas particuliers, et ce qu’il faut faire quand quelque chose se passe mal. Elle porte un numéro de version, une date, un rédacteur et un validateur, sans quoi personne ne sait si elle est à jour. L’assistant structure et reformule ; il ne connaît pas l’organisation et ne décide pas des rôles. Quand la procédure encadre l’usage d’un outil d’IA, elle se relie au registre des usages (Skill registre-usages-ia). Prudence générale : ne pas mettre dans la procédure ni dans l’outil de mots de passe, de données personnelles ou d’informations confidentielles. ## Marche à suivre 1. Demander l’objet de la procédure, son périmètre, les personnes qui la réalisent aujourd’hui et ce qui pose problème. 2. Faire décrire le déroulement réel, étape par étape, par la personne qui fait la tâche ; noter les variantes et les raccourcis. 3. Rédiger les étapes numérotées, chacune avec un verbe d’action, un rôle (pas un nom de personne) et le résultat attendu. 4. Ajouter les cas particuliers, les points de contrôle et la conduite à tenir en cas de problème, avec la personne à prévenir. 5. Faire relire par une personne qui ne connaît pas la tâche : ce qu’elle ne comprend pas est à réécrire. 6. Soumettre au responsable, qui valide, date, numérote la version et décide de la diffusion. Fixer une date de révision. ## Lignes rouges - Ne jamais inventer une étape, un contrôle ou un outil qui n’existe pas dans la pratique décrite. - Ne jamais attribuer un rôle ou une responsabilité que le responsable n’a pas validé. - Ne jamais diffuser une procédure sans version, date et nom du validateur. - Ne jamais y inscrire de mot de passe, d’identifiant ou de donnée personnelle. ## Ce que la Skill ne fait pas Elle ne décide pas de l’organisation du travail, ne vérifie pas que la procédure est appliquée et ne remplace pas la formation des personnes. ## Modèle de sortie ~~~ PROCÉDURE : ... VERSION : ... DATE : ... RÉDIGÉE PAR : ... VALIDÉE PAR : ... RÉVISION PRÉVUE LE : ... OBJET ET PÉRIMÈTRE : ... ÉTAPES 1. [verbe] ... / rôle : ... / résultat : ... 2. ... CAS PARTICULIERS : ... EN CAS DE PROBLÈME : prévenir ... / faire ... DOCUMENTS ET OUTILS LIÉS : ... ~~~

Copier le SKILL.md

--- name: registre-usages-ia description: "Construit et met à jour le registre des usages de l’intelligence artificielle d’une organisation : pour chaque usage, l’outil, la finalité, les données qui y entrent, le niveau de risque, la personne responsable et la date de revue. À utiliser quand une équipe commence à utiliser des outils d’IA, avant un audit, ou quand un nouvel outil est adopté." --- # Tenir le registre des usages de l’IA ## Quand s’en servir Au premier usage d’un outil d’IA dans une équipe. À chaque nouvel outil ou nouvelle finalité. Avant un audit, une visite d’une autorité, une demande d’un client ou d’un délégué à la protection des données. Une fois par trimestre pour la revue. ## Ce que l’assistant doit savoir Le registre n’est pas une contrainte administrative : c’est la seule pièce qui permet de répondre en cinq minutes à « qui utilise quoi, avec quelles données, et qui en répond ». Le règlement européen sur l’IA impose aux organisations qui déploient des systèmes d’IA de savoir ce qu’elles utilisent et de former les personnes concernées ; le RGPD impose de savoir quelles données personnelles sont traitées et pourquoi. Le registre sert les deux. ## Marche à suivre 1. Lister les usages réels, pas les usages théoriques. Demander à chaque équipe : « quel outil avez-vous utilisé cette semaine, pour faire quoi ? » 2. Pour chaque usage, remplir une ligne avec les colonnes du modèle ci-dessous. Une ligne = un couple outil et finalité. Le même outil utilisé pour deux finalités fait deux lignes. 3. Qualifier les données qui entrent : aucune donnée personnelle / données personnelles ordinaires / données sensibles (santé, opinions, données de mineurs, données pénales). La troisième catégorie déclenche une revue immédiate. 4. Qualifier le niveau de risque selon le vocabulaire de la page Réglementation de wiikiiaii.com (minimal, limité, élevé, inacceptable). En cas de doute, écrire « à qualifier » plutôt qu’un niveau deviné. 5. Nommer une personne responsable par ligne. Une ligne sans nom est une ligne dont personne ne répond. 6. Fixer une date de revue à chaque ligne. Trois mois par défaut, un mois pour les usages à risque élevé. 7. Rendre le registre et une liste des lignes qui appellent une action : données sensibles, risque élevé, responsable manquant, revue dépassée. ## Garde-fous - Ne jamais qualifier un risque « minimal » pour clore le sujet. Le doute se note, il ne se tranche pas seul. - Un outil grand public utilisé avec des données de clients ou de salariés est un usage à inscrire, même s’il est « juste pour tester ». - Le registre ne remplace ni l’analyse d’impact (RGPD) ni la documentation exigée pour un système à haut risque : il dit où elles sont nécessaires. ## Ce que la Skill ne fait pas Elle ne décide pas du niveau de risque juridique : elle applique un vocabulaire et signale les cas à faire trancher par un responsable conformité ou un délégué à la protection des données. ## Modèle de registre ~~~ | Usage | Outil | Finalité | Données qui entrent | Risque | Responsable | Revue le | Action | |---|---|---|---|---|---|---|---| | Réponses aux courriels clients | ... | brouillons de réponses | données personnelles ordinaires | limité | ... | 2026-12-01 | aucune | ~~~

Copier le SKILL.md

--- name: trace-des-productions-ia description: Aide l’assistant à organiser la trace d’une production faite avec un outil d’IA (outil et version, instructions, sources, date, relecteur, modifications humaines) pour pouvoir expliquer plus tard comment un résultat a été obtenu. À utiliser dès qu’un livrable, un texte ou une analyse produit avec une IA sort de la structure ou sert à une décision. --- # Garder la trace de ce qui a été produit avec un outil d’IA ## Quand s’en servir Mettre en place une fiche de trace pour les livrables produits avec une IA. Décider ce qu’on garde et ce qu’on ne garde pas. Compléter la trace d’un travail déjà rendu tant que les éléments sont encore disponibles. Préparer ce qui servira, le jour venu, à la Skill dossier-de-preuve-en-cas-de-contestation. ## Ce que l’assistant doit savoir Une trace utile répond à une seule question : comment ce résultat a-t-il été obtenu, et qui l’a validé ? Elle tient en quelques champs : l’outil et sa version ou son abonnement, la date, les instructions données, les sources fournies ou citées, ce que l’humain a modifié, le nom de la personne qui a relu et validé. Garder tout, tout le temps, n’est pas une bonne trace : le RGPD impose la minimisation des données (art. 5 §1 c), et une instruction contenant des données personnelles se conserve comme une donnée personnelle. Pour les systèmes à haut risque, le règlement européen sur l’IA impose en plus au déployeur de conserver les journaux du système au moins six mois (art. 26 §6), à partir du 2 décembre 2027 ; c’est distinct de la trace éditoriale décrite ici. La trace alimente le registre tenu avec la Skill registre-usages-ia. ## Marche à suivre 1. Demander quels livrables sont concernés, où ils sont stockés, et qui les relit aujourd’hui. Partir de l’existant plutôt que d’un outil nouveau. 2. Proposer une fiche de trace courte, adaptée au type de production (texte, code, image, analyse chiffrée), avec les seuls champs qui répondent à la question « comment ce résultat a-t-il été obtenu ». 3. Repérer les champs qui contiendraient des données personnelles ou confidentielles, et proposer de les remplacer par une référence au dossier source plutôt que par une copie. 4. Faire fixer par l’humain la durée de conservation et l’endroit où la trace est rangée ; noter qui en est responsable. 5. Remplir la fiche avec l’utilisateur pour un premier livrable réel, et signaler les champs qu’il n’a pas pu renseigner. 6. Rappeler ce qui reste à la personne : la relecture, la validation, la signature du livrable. ## Lignes rouges - Ne jamais reconstituer après coup une instruction, une source ou une date qu’on ne retrouve pas : écrire « non conservé ». - Ne jamais copier dans la trace des données personnelles ou couvertes par un secret quand une référence suffit. - Ne jamais indiquer qu’un livrable a été relu sans le nom de la personne qui l’a fait. - Ne jamais présenter la trace comme une preuve de conformité : elle montre comment on a travaillé, pas que c’était licite. ## Ce que la Skill ne fait pas Elle ne choisit pas l’outil d’archivage, ne fixe pas la durée de conservation à la place de la structure et ne remplace ni le registre des usages ni les journaux techniques d’un système. ## Modèle de sortie ~~~ LIVRABLE : ... OUTIL ET VERSION : ... DATE : ... INSTRUCTIONS (ou référence) : ... SOURCES FOURNIES / CITÉES : ... MODIFICATIONS HUMAINES : ... RELU ET VALIDÉ PAR : ... LE : ... NON CONSERVÉ : ... CONSERVATION : durée ... / lieu ... / responsable ... ~~~

Copier le SKILL.md

--- name: relecture-editoriale description: "Relit un texte destiné à être publié sur wiikiiaii.com ou remis à un client selon la charte de la plateforme : français clair, pas de tiret cadratin, aucune affirmation sans date ni source de premier rang, garde-fous visibles. À utiliser avant toute publication d’un article, d’une fiche, d’un prompt ou d’un document de formation, et chaque fois qu’un texte parle de droit, de prix ou de chiffres." --- # Relecture éditoriale wiikiiaii ## Quand s’en servir Avant toute publication ou remise : article, fiche outil, page métier, prompt, support de formation, courriel à un client. Dès qu’un texte contient une date, un prix, un chiffre, une citation de texte réglementaire ou une promesse. ## Ce que l’assistant doit savoir wiikiiaii.com est une plateforme française de littératie IA, publiée par une association loi 1901. Son actif n’est pas la quantité de contenu mais sa vérifiabilité : chaque affirmation datée engage tout le document. Un texte relu ici doit pouvoir être cité par un lecteur devant son employeur ou son client sans que celui-ci trouve une erreur. ## Marche à suivre 1. Lire le texte en entier une première fois sans corriger. Noter en une ligne ce qu’il promet au lecteur. 2. Relever chaque affirmation vérifiable : date, montant, nombre, nom de texte réglementaire, nom d’outil, version. Pour chacune, demander : d’où vient-elle, et à quelle date était-elle vraie ? 3. Signaler toute affirmation sans source de premier rang (texte officiel, page de l’éditeur, publication de l’autorité). Ne pas inventer la source : la demander. 4. Vérifier la forme : français, phrases courtes, pas de tiret cadratin (remplacer par deux points, une virgule ou un point), pas d’anglicisme évitable, chiffres avec espace insécable comme séparateur de milliers. 5. Vérifier que les garde-fous sont visibles : si le texte propose un usage de l’IA, dit-il ce que l’IA ne doit pas décider seule, et quelles données ne doivent pas y entrer ? 6. Rendre le texte corrigé, puis une liste séparée des points qui exigent une décision humaine. ## Garde-fous - Ne jamais rafraîchir une date « pour faire récent ». Une date affichée signifie « relu à cette date ». - Ne jamais arrondir un chiffre pour le rendre plus parlant sans le dire. - Une affirmation de droit sans article ni texte cité est à retirer ou à sourcer, jamais à laisser « parce que c’est connu ». - Le ton est celui d’un formateur qui s’adresse à un professionnel, pas celui d’une publicité. ## Ce que la Skill ne fait pas Elle ne vérifie pas le droit à votre place : elle signale ce qui doit l’être. L’état du droit fait foi sur la page Réglementation de wiikiiaii.com, pas dans une mémoire d’assistant. ## Modèle de sortie ~~~ TEXTE RELU [le texte corrigé] À TRANCHER PAR UN HUMAIN 1. [affirmation] : source manquante / date incertaine / promesse à confirmer 2. ... ~~~

Copier le SKILL.md

--- name: contenu-faux-deja-diffuse description: Guide l’assistant dans les premières heures après la diffusion d’un contenu faux produit avec une IA (article, fiche, publication, courrier, image) pour qualifier l’erreur, faire retirer, préparer la correction et le message, et tracer chaque geste. À utiliser dès qu’une erreur publiée est signalée, par un lecteur, un client, un collègue ou une personne concernée. --- # Réagir quand un contenu faux produit avec une IA est déjà sorti ## Quand s’en servir Une fausse information, une citation inventée, une référence inexistante ou une image trompeuse a été publiée ou envoyée. Quelqu’un le signale. La structure doit décider vite quoi retirer, quoi corriger et quoi dire. ## Ce que l’assistant doit savoir La vitesse compte, mais la précipitation aggrave : corriger une erreur par une autre est fréquent. Il faut d’abord établir ce qui est faux, prouvé par une source, puis mesurer qui a pu être touché. Selon le contenu, d’autres règles se superposent : une allégation commerciale fausse peut constituer une pratique commerciale trompeuse (Code de la consommation, L. 121-2) ; un contenu qui met en cause une personne ou révèle des données personnelles appelle aussi la Skill donnees-parties-dans-un-outil. Le règlement européen sur l’IA, depuis le 2 août 2026, impose aux déployeurs d’indiquer qu’un hypertrucage a été généré ou manipulé (art. 50 §4) : voir la Skill marquer-ce-qui-doit-l-etre. La décision de retirer, de corriger publiquement et de s’excuser appartient à l’humain responsable de la publication. ## Marche à suivre 1. Demander le contenu exact, où et quand il a été diffusé, par quel canal, et qui a signalé l’erreur. 2. Isoler ce qui est faux et ce qui ne l’est pas, en retrouvant la source primaire (Skill sourcage-premier-rang). Ne rien qualifier de faux sans cette vérification. 3. Évaluer l’exposition : audience, reprises, personnes nommées, conséquences possibles. Signaler les cas qui appellent un conseil juridique. 4. Proposer à l’humain les gestes immédiats : retrait, dépublication, mise en attente, avertissement aux relais. 5. Rédiger une correction datée qui dit ce qui était faux et ce qui est exact, sans minimiser, et un message pour les personnes directement touchées. 6. Ouvrir une trace horodatée de chaque geste et préparer le retour d’expérience (Skill retour-d-experience-apres-incident). ## Lignes rouges - Ne jamais supprimer un contenu sans en garder une copie datée pour le dossier. - Ne jamais publier une correction qui n’a pas été vérifiée à la source et validée par l’humain. - Ne jamais attribuer publiquement l’erreur à « l’IA » pour dégager la responsabilité de la structure. - Ne jamais contacter une personne mise en cause au nom de la structure sans décision humaine. ## Ce que la Skill ne fait pas Elle ne décide pas du retrait ni de la communication, ne qualifie pas une diffamation et ne remplace pas la cellule de crise ou le conseil juridique. ## Modèle de sortie ~~~ CONTENU : ... DIFFUSÉ LE : ... CANAL / AUDIENCE : ... CE QUI EST FAUX (source) : ... CE QUI EST EXACT : ... EXPOSITION : reprises ... / personnes nommées ... GESTES PROPOSÉS : retrait ... / correction ... / message ... TRACE : (heure) geste ... par ... À DÉCIDER PAR VOUS : retrait, texte de correction, destinataires ~~~