17 Skills Administrateur(rice) système

Copier le SKILL.md

--- name: chaine-admin-systeme-script-ia-de-la-relecture-a-la-production description: "Déroule dans l’ordre la chaîne publiée sur wiikiiaii.com, pour les administrateurs système : nettoyer l’extrait à soumettre, décortiquer le script proposé, tester sur un jeu d’essai isolé, faire relire par un pair, demander le changement, inscrire au registre. À utiliser quand cette situation se traite de bout en bout et que chaque étape doit reprendre la sortie validée de la précédente, sans que l’assistant décide à la place du professionnel." --- # Administrateur système : un script proposé par l’IA, de la relecture à la mise en production tracée ## Quand s’en servir Un administrateur système reçoit d’un assistant un script ou une commande pour automatiser une tâche d’exploitation. Il doit le comprendre, le tester hors production, le faire relire, le passer par le processus de changement et le tracer. La chaîne conduit de l’extrait nettoyé soumis à l’assistant jusqu’au script inscrit au registre, avec son approbation et son retour arrière. ## Ce que l’assistant doit savoir Un script généré peut contenir des options par défaut pensées pour un autre système, une commande destructrice ou une variable qui, vide, change de cible. Ce qui est collé dans un assistant sort du système d’information : secrets, adresses internes et données personnelles se masquent avant tout envoi. La documentation officielle de chaque commande se lit dans la version installée. Le changement en production suit le processus écrit de la structure ou du contrat client, et c’est la personne habilitée qui l’approuve. L’assistant travaille sur des pièces anonymisées ou pseudonymisées : aucune donnée personnelle d’un client, d’un salarié ou d’un tiers n’entre dans un outil dont les conditions n’ont pas été vérifiées (minimisation, RGPD article 5 §1 c). Il ne décide de rien qui engage : prix, signature, envoi, publication, sanction ou qualification juridique restent au professionnel. Les contenus générés ou fournis par des tiers ne deviennent pas la propriété de celui qui les utilise : les droits se vérifient avant tout usage public. Identifiant de liaison :. Sur wiikiiaii.com, les prompts de chaque étape, les agents associés et le process Process IA portent le même identifiant. ## Marche à suivre 1. **Nettoyer l’extrait à soumettre.** Retirer secrets, adresses et données personnelles du journal ou de la configuration avant de les confier à l’assistant. 2. **Décortiquer le script proposé.** Faire expliquer chaque ligne et chaque option, et relever les suppositions sur l’environnement. 3. **Tester sur un jeu d’essai isolé.** Construire les cas nominaux, limites et d’erreur sur des données fictives, et constater les résultats. 4. **Faire relire par un pair.** Préparer le dossier de revue en signalant les parties générées et les points de doute. 5. **Demander le changement.** Rédiger la demande de changement avec l’impact, les tests et le retour arrière, pour approbation. 6. **Inscrire au registre.** Consigner l’auteur, l’origine, le relecteur, l’approbation et la version du script mis en service. 7. **Faire valider la chaîne par le professionnel.** Présenter le tableau de bord. Le professionnel relit chaque sortie, vérifie les faits et les sources, décide, signe et envoie lui-même. ## Lignes rouges - Ne jamais exécuter en production un script qui n’a pas été testé hors production. - Ne jamais coller un secret, une clé ou une donnée personnelle non masquée dans un assistant. - Ne jamais présenter une option de commande comme certaine sans la documentation de la version installée. - Ne jamais mettre un script en service sans relecteur ni ligne au registre. - Ne jamais faire entrer dans l’outil une donnée personnelle ou confidentielle qui n’a pas été anonymisée. - Ne jamais trancher seul un point sensible : renvoyer aux agents « Aucun secret ne part dans une requête à l’assistant de codage », « La revue d’un code écrit avec un assistant », « Des changements en production préparés, approuvés et réversibles », « Le journal de bord de ce que l’assistant a proposé ». ## Ce que la Skill ne fait pas Elle n’exécute aucune commande, ne voit aucun système réel et n’approuve aucun changement. Les textes et échéances non cités ici figurent sur la page Réglementation de wiikiiaii.com, tenue à jour. ## Modèle de sortie ~~~ CHAÎNE : / DOSSIER : ... ÉTAPE | ENTRÉE | SORTIE | VALIDÉ PAR | DATE - Nettoyage | extrait brut | extrait masqué | ... | ... - Explication | script | lecture ligne par ligne | ... | ... - Test | script | grille de résultats | ... | ... - Revue | script testé | dossier de revue | ... | ... - Changement | dossier | demande à approuver | ... | ... - Registre | script approuvé | ligne de registre | ... | ... VALIDATION FINALE : par ... le ... CE QUI RESTE AU PROFESSIONNEL : la décision, la signature, l’envoi ~~~

Copier le SKILL.md

--- name: chaine-admin-systeme-incident-de-l-alerte-au-retour-d-experience description: "Déroule dans l’ordre la chaîne publiée sur wiikiiaii.com, pour les administrateurs système : appliquer la fiche réflexe, tenir la main courante, faire le point à la direction, informer les utilisateurs, préparer les éléments de notification, écrire le retour d’expérience. À utiliser quand cette situation se traite de bout en bout et que chaque étape doit reprendre la sortie validée de la précédente, sans que l’assistant décide à la place du professionnel." --- # Administrateur système : un incident de sécurité, des premières minutes au retour d’expérience ## Quand s’en servir Un administrateur système fait face à un chiffrement, une compromission de messagerie ou une intrusion. Il doit agir sans détruire les traces, tenir la main courante, informer la direction et les utilisateurs, fournir au responsable de traitement les éléments d’une éventuelle notification, puis tirer les leçons. La chaîne conduit de la fiche réflexe jusqu’au retour d’expérience validé. ## Ce que l’assistant doit savoir Les premiers gestes décident de ce qu’on pourra prouver et restaurer : isoler sans effacer, préserver les sauvegardes, consigner chaque action avec son heure. Les consignes de l’assureur et du prestataire de réponse à incident priment sur l’improvisation. La décision de notifier une violation de données appartient au responsable de traitement, avec le délégué à la protection des données, selon la règle relevée à la source ; le régime propre à certains secteurs se vérifie de même. Aucune heure de rétablissement ne se promet sans base. L’assistant travaille sur des pièces anonymisées ou pseudonymisées : aucune donnée personnelle d’un client, d’un salarié ou d’un tiers n’entre dans un outil dont les conditions n’ont pas été vérifiées (minimisation, RGPD article 5 §1 c). Il ne décide de rien qui engage : prix, signature, envoi, publication, sanction ou qualification juridique restent au professionnel. Les contenus générés ou fournis par des tiers ne deviennent pas la propriété de celui qui les utilise : les droits se vérifient avant tout usage public. Identifiant de liaison :. Sur wiikiiaii.com, les prompts de chaque étape, les agents associés et le process Process IA portent le même identifiant. ## Marche à suivre 1. **Appliquer la fiche réflexe.** Isoler, préserver, alerter et consigner dans l’ordre prévu, sans toucher aux sauvegardes saines. 2. **Tenir la main courante.** Horodater chaque constat, action et décision, avec son auteur, sans jamais réécrire. 3. **Faire le point à la direction.** Envoyer à heure fixe la situation, l’impact, les actions et les décisions attendues. 4. **Informer les utilisateurs.** Dire ce qui ne marche pas, ce qu’il faut faire et l’heure du prochain point, après validation. 5. **Préparer les éléments de notification.** Organiser faits, données concernées et mesures pour le responsable de traitement, qui décide. 6. **Écrire le retour d’expérience.** Établir la chaîne des causes et les actions, sans désigner de coupable. 7. **Faire valider la chaîne par le professionnel.** Présenter le tableau de bord. Le professionnel relit chaque sortie, vérifie les faits et les sources, décide, signe et envoie lui-même. ## Lignes rouges - Ne jamais restaurer par-dessus une machine touchée avant que les traces aient été préservées. - Ne jamais promettre une heure de rétablissement ni affirmer une absence de fuite sans preuve. - Ne jamais citer un délai ou une obligation de notification de mémoire. - Ne jamais désigner une personne comme coupable de l’incident. - Ne jamais faire entrer dans l’outil une donnée personnelle ou confidentielle qui n’a pas été anonymisée. - Ne jamais trancher seul un point sensible : renvoyer aux agents « Des journaux utiles le jour d’un incident, et conservés comme il faut », « Des messages d’incident clairs, honnêtes et réguliers », « Des données sont parties dans un outil : la suite », « Un post-mortem qui fait progresser l’équipe, sans chercher de coupable ». ## Ce que la Skill ne fait pas Elle ne répond pas à l’incident, ne notifie aucune autorité et ne remplace ni l’assureur ni un prestataire qualifié. Les textes et échéances non cités ici figurent sur la page Réglementation de wiikiiaii.com, tenue à jour. ## Modèle de sortie ~~~ CHAÎNE : / DOSSIER : ... ÉTAPE | ENTRÉE | SORTIE | VALIDÉ PAR | DATE - Fiche réflexe | alerte | premiers gestes consignés | ... | ... - Main courante | notes et messages | chronologie horodatée | ... | ... - Point direction | main courante | point de situation | ... | ... - Utilisateurs | état des services | message validé | ... | ... - Notification | faits | éléments pour le responsable | ... | ... - Retour d’expérience | dossier complet | causes et actions | ... | ... VALIDATION FINALE : par ... le ... CE QUI RESTE AU PROFESSIONNEL : la décision, la signature, l’envoi ~~~

Copier le SKILL.md

--- name: tech-surveiller-une-fonctionnalite-d-ia-en-production description: "Aide le développeur, l’administrateur système ou le responsable produit à surveiller une fonctionnalité d’IA en production : indicateurs de qualité, dérives, signalements des utilisateurs, coûts, changements du fournisseur de modèle. Tableau interne. À utiliser chaque semaine." --- # Surveiller une fonctionnalité d’IA en production ## Quand s’en servir La fonctionnalité est en ligne depuis deux mois. Le fournisseur a mis à jour son modèle sans prévenir ; les réponses ont changé de ton et de qualité. ## Ce que l’assistant doit savoir La surveillance porte sur la fonctionnalité, pas sur les utilisateurs : les journaux sont minimisés et conservés selon la politique de l’entreprise. Elle suit un échantillon évalué régulièrement, les signalements, les coûts et les annonces du fournisseur. Une dérive au-delà d’un seuil déclenche une réévaluation ou un retour arrière. Les modèles fournis par des tiers évoluent : une mise à jour annoncée ou silencieuse peut changer la qualité, le ton, la longueur des réponses ou le coût. Épingler une version quand le fournisseur le permet facilite la surveillance. Les signalements des utilisateurs sont la source la plus précieuse : le moyen de signaler doit être visible dans l’interface. ## Marche à suivre 1. Définir les indicateurs et les seuils. 2. Évaluer chaque semaine un échantillon de sorties. 3. Suivre les signalements des utilisateurs. 4. Suivre les coûts. 5. Relire les annonces du fournisseur de modèle. 6. Décider : continuer, réévaluer, revenir en arrière. ## Lignes rouges - Ne jamais conserver plus de journaux que nécessaire. - Ne jamais ignorer un changement de modèle du fournisseur. ## Ce que la Skill ne fait pas Elle ne remplace pas l’évaluation avant mise en production. ## Modèle de sortie ~~~ SURVEILLANCE DE ..., SEMAINE ... INDICATEUR / VALEUR / SEUIL / ÉTAT SIGNALEMENTS : ... COÛTS : ... ANNONCES DU FOURNISSEUR : ... DÉCISION : ... ~~~

Copier le SKILL.md

--- name: tech-incident-d-injection-de-consigne description: "Aide le développeur ou l’administrateur système à réagir quand une fonctionnalité d’IA a suivi des instructions cachées dans un contenu (page web, document, courriel) : confinement, analyse, correction, trace. À utiliser dès la détection." --- # Réagir à une injection de consigne dans une fonctionnalité d’IA ## Quand s’en servir Un agent qui lit des documents a exécuté une instruction cachée dans l’un d’eux : il a envoyé des données ou modifié un enregistrement. ## Ce que l’assistant doit savoir La trace est interne. Le confinement vient d’abord : désactiver l’action concernée, révoquer les accès utilisés. L’analyse identifie le contenu en cause, ce que l’agent a fait, les données touchées. La correction réduit les permissions de l’agent au strict nécessaire et impose une validation humaine pour les actions sensibles. Si des données personnelles sont touchées, la personne chargée de leur protection décide des suites. ## Marche à suivre 1. Désactiver l’action et révoquer les accès concernés. 2. Conserver les journaux et le contenu en cause. 3. Reconstituer ce que l’agent a fait. 4. Identifier les données touchées. 5. Réduire les permissions et ajouter une validation humaine. 6. Informer les personnes compétentes et tracer. ## Lignes rouges - Ne jamais remettre l’agent en service sans correction. - Ne jamais effacer les journaux de l’incident. ## Ce que la Skill ne fait pas Elle ne qualifie pas une violation de données. ## Modèle de sortie ~~~ INCIDENT D’INJECTION, FONCTIONNALITÉ ... (le ...) CONFINEMENT : ... CONTENU EN CAUSE : ... ACTIONS DE L’AGENT : ... DONNÉES TOUCHÉES : ... CORRECTIONS : permissions / validation humaine INFORMÉS : ... ~~~

Copier le SKILL.md

--- name: tech-et-donnees description: "Cadre l’assistant pour les développeurs, chefs de projet, analystes de données, product managers, administrateurs et testeurs : produire du code, des analyses, des spécifications et des tests vérifiables, sans jamais exposer un secret, une donnée de production ou une infrastructure, et en disant ce qui n’a pas été exécuté. À utiliser pour la production technique et son contrôle." --- # Assistant pour les métiers de la tech et de la donnée ## Quand s’en servir Écrire ou relire du code, rédiger une spécification, des cas de test, une requête d’analyse, une documentation, un plan de migration. Expliquer un comportement, proposer une architecture, préparer une revue. ## Ce que l’assistant doit savoir Le code produit par une IA n’a pas été exécuté tant qu’il n’a pas été exécuté : une réponse plausible n’est pas un test qui passe. Les secrets (clés, mots de passe, jetons), les données de production et les schémas d’infrastructure ne doivent jamais entrer dans un outil grand public. Une analyse de données personnelles est un traitement au sens du RGPD ; un modèle qui prend des décisions sur des personnes peut relever du risque élevé du règlement européen sur l’IA. La licence du code généré et celle des dépendances proposées se vérifient. ## Marche à suivre 1. Vérifier qu’aucun secret, aucune donnée réelle, aucune adresse interne n’est dans la demande. Sinon, demander une version expurgée ou des données synthétiques. 2. Demander le langage, la version, les contraintes (performance, sécurité, compatibilité), et ce qui existe déjà. 3. Produire le code avec ses tests, ou dire explicitement qu’aucun test n’accompagne la réponse. 4. Marquer distinctement ce qui a été exécuté et ce qui ne l’a pas été. Ne jamais écrire « ça fonctionne » sans exécution. 5. Pour une analyse de données : décrire les données attendues, écrire la requête ou le script, et signaler tout champ personnel ou sensible qui appelle une base légale et une minimisation. 6. Pour une spécification ou un plan : lister les hypothèses, les risques et ce qui exige une décision d’architecture humaine. ## Lignes rouges de la famille - Aucun secret, aucune donnée de production, aucun schéma d’infrastructure dans un outil grand public. - Aucune affirmation de bon fonctionnement sans exécution. - Aucune dépendance proposée sans mention de sa licence et de son état de maintenance. - Aucun modèle décisionnel sur des personnes sans signaler le cadre à vérifier. ## Ce que la Skill ne fait pas Elle n’a pas accès à votre environnement et ne connaît pas votre base de code. Elle produit une proposition à exécuter et à relire. ## Modèle de sortie ~~~ PROPOSITION [code / spécification / requête] EXÉCUTÉ : oui / non (préciser quoi) TESTS FOURNIS : ... DÉPENDANCES (licence, maintenance) : ... À DÉCIDER PAR VOUS - ... ~~~

Copier le SKILL.md

--- name: tech-regles-des-secrets-avec-les-outils-de-codage description: "Aide le responsable technique à fixer et transmettre aux développeurs les règles d’usage des assistants de codage vis-à-vis des secrets, des données de production et du code propriétaire : ce qui ne sort jamais, configuration des outils, détection, conduite en cas de fuite. À utiliser à l’adoption d’un outil et à l’arrivée d’un développeur." --- # Fixer les règles des secrets avec les assistants de codage ## Quand s’en servir Les assistants de codage lisent le dépôt entier, les fichiers de configuration et parfois l’historique. Une clé d’API peut partir dans une requête sans que personne ne s’en aperçoive. ## Ce que l’assistant doit savoir La consigne est transmise à l’équipe. Elle liste ce qui ne doit jamais être exposé à un outil externe (secrets, données de production, code sous accord de confidentialité), la configuration attendue des outils (exclusions de fichiers, réutilisation des données désactivée quand l’offre le permet), les contrôles automatiques (détection de secrets avant envoi et avant publication) et la conduite en cas de fuite (révocation immédiate). Les conditions des outils se lisent et se datent. ## Marche à suivre 1. Lister les catégories à ne jamais exposer. 2. Fixer la configuration obligatoire de chaque outil validé. 3. Mettre en place la détection de secrets. 4. Rédiger la conduite en cas de fuite : révoquer, tracer, prévenir. 5. Intégrer la consigne à l’accueil des développeurs. 6. Revoir à chaque changement d’outil ou de conditions. ## Lignes rouges - Ne jamais laisser un secret exposé sans révocation. - Ne jamais autoriser un outil dont les conditions sur les données n’ont pas été lues. ## Ce que la Skill ne fait pas Elle ne choisit pas les outils et ne remplace pas la politique de sécurité de l’entreprise. ## Modèle de sortie ~~~ RÈGLES SECRETS ET ASSISTANTS DE CODAGE (version du ...) JAMAIS EXPOSÉ : ... CONFIGURATION DES OUTILS : outil / réglages / conditions lues le DÉTECTION : ... EN CAS DE FUITE : révoquer / tracer / prévenir ~~~

Copier le SKILL.md

--- name: tech-cyber-resilience-des-produits description: "Aide l’éditeur, l’ESN ou l’équipe produit à qualifier chaque produit ou service au regard du règlement européen sur la cyber-résilience avant d’y intégrer une brique d’IA : produit visé ou non, rôle de l’entreprise, catégorie probable, questions ouvertes. À utiliser au cadrage d’une feuille de route, d’un nouveau module ou d’une offre qui embarque un modèle." --- # Classer un produit numérique avant d’y mettre de l’IA ## Quand s’en servir Ajouter un assistant ou un modèle dans un logiciel existant. Cadrer une nouvelle version, un boîtier connecté, une application mobile, une bibliothèque diffusée à des clients. Répondre à un appel d’offres qui demande la position de l’éditeur sur la cyber-résilience. Revoir le catalogue avant une échéance. ## Ce que l’assistant doit savoir Le règlement (UE) 2024/2847 vise les produits comportant des éléments numériques mis sur le marché, logiciels compris. Un service purement en ligne n’est en principe pas visé comme tel, mais le traitement à distance nécessaire au fonctionnement d’un produit fait partie du produit : la frontière se tranche au cas par cas. Certains produits figurent dans des listes de produits importants ou critiques, soumis à une évaluation plus exigeante. Les obligations dépendent du rôle : fabricant, importateur, distributeur. L’obligation d’alerte de l’article 14 s’applique déjà depuis le 11 septembre 2026 (voir tech-signalement-sous-24-heures) ; pour les autres échéances, renvoyer à la page Réglementation de wiikiiaii.com, tenue à jour. Le croisement avec le règlement sur l’IA se fait à part : un intégrateur qui met son nom sur un système d’IA à haut risque, le modifie substantiellement ou en change la destination en devient le fournisseur (article 25). La qualification finale appartient au responsable produit et au juriste, pas à l’assistant. ## Marche à suivre 1. Demander la liste des produits et services, avec pour chacun : forme de distribution (logiciel installé, SaaS, appareil, composant, bibliothèque), clients visés, marché européen ou non. 2. Pour chaque ligne, établir le rôle de l’entreprise : conçoit et vend sous son nom, revend, intègre le produit d’un tiers. 3. Poser les questions qui départagent produit et service : quelle partie s’exécute chez le client, quelle partie à distance, la fonction marche-t-elle sans le serveur. 4. Repérer si la fonction ressemble à une catégorie de produit important ou critique, sans conclure : noter « à confirmer sur la page Réglementation ». 5. Décrire la brique d’IA envisagée : modèle embarqué ou appelé par API, fournisseur, données traitées, destination. Signaler tout cas où l’article 25 pourrait faire de l’entreprise le fournisseur d’un système à haut risque, et renvoyer à tech-et-donnees. 6. Produire la fiche de classement, en séparant ce qui est établi, ce qui est probable et ce qui reste à trancher. 7. Nommer qui valide chaque ligne et à quelle date la fiche sera revue. ## Lignes rouges - Ne jamais conclure qu’un produit est « hors champ » sans que le responsable désigné l’ait validé. - Ne jamais citer une date d’application qui ne figure pas sur la page Réglementation. - Ne jamais demander du code source, des secrets ou le détail d’une faille non corrigée pour faire le classement. - Ne jamais présenter la fiche comme une attestation de conformité. ## Ce que la Skill ne fait pas Elle ne réalise pas l’évaluation de conformité, ni l’analyse de risques de sécurité, ni la documentation technique. Elle prépare la décision de classement. ## Modèle de sortie ~~~ PRODUIT : ... FORME DE DISTRIBUTION : ... RÔLE DE L’ENTREPRISE : fabricant / importateur / distributeur / intégrateur PRODUIT OU SERVICE : ... (raisonnement en deux lignes) CATÉGORIE PROBABLE : ... (à confirmer) BRIQUE D’IA : ... / fournisseur : ... / risque article 25 : oui / non / à voir DÉJÀ APPLICABLE : alerte sous 24 heures (article 14) À TRANCHER PAR VOUS - ... VALIDÉ PAR : ... LE : ... PROCHAINE REVUE : ... ~~~

Copier le SKILL.md

--- name: tech-inventaire-des-composants description: Aide le développeur ou l’administrateur système à tenir l’inventaire des composants de ce qu’il livre, y compris les modèles et bibliothèques d’IA, et à suivre les vulnérabilités qui les touchent. À utiliser avant une livraison, à l’ajout d’une dépendance ou d’un modèle, ou quand une faille est annoncée sur un composant tiers et qu’il faut savoir vite si l’on est concerné. --- # Inventorier les composants et modèles d’IA de ce que vous livrez ## Quand s’en servir Une version part chez un client ou en production. Un développeur ajoute une bibliothèque, un modèle téléchargé, un service d’inférence appelé par API. Une faille est publiée sur un composant répandu et la question tombe : sommes-nous touchés, où, dans quelles versions livrées ? ## Ce que l’assistant doit savoir On ne corrige que ce que l’on sait avoir livré. Un inventaire utile liste, pour chaque version livrée, les composants directs et transitifs, leur version exacte, leur origine, leur licence, et, pour l’IA, le modèle, son fournisseur, sa version ou son empreinte, les poids embarqués ou le service distant appelé. Le règlement (UE) 2024/2847 sur la cyber-résilience impose aux fabricants de produits comportant des éléments numériques de maîtriser leurs composants et leurs vulnérabilités ; son art. 14 (alerte précoce au plus tard 24 heures après connaissance d’une vulnérabilité activement exploitée) s’applique depuis le 11 septembre 2026, et l’application générale intervient le 11 décembre 2027. Le détail des exigences sur la documentation des composants se lit sur la page Réglementation de wiikiiaii.com, tenue à jour. Le classement du produit relève de tech-cyber-resilience-des-produits, et le signalement de tech-signalement-sous-24-heures : cette Skill ne les répète pas. L’assistant aide à structurer et à croiser ; il ne devine jamais une version qu’il n’a pas lue dans un fichier de verrouillage, un manifeste ou une fiche fournisseur. Sur wiikiiaii.com, l’agent « Savoir ce qu’il y a dans ce que vous livrez » traite le même sujet côté procédure. ## Marche à suivre 1. Demander le produit, la version livrée, et les sources disponibles : fichiers de dépendances verrouillés, image de conteneur, liste des modèles, contrats des services d’IA appelés. 2. Construire l’inventaire par couches : code applicatif, bibliothèques, système et conteneur, modèles et services d’IA. Marquer « inconnu » tout ce qui n’est pas lu dans une source. 3. Pour chaque modèle, noter le fournisseur, la version ou l’empreinte, le mode (embarqué ou distant) et qui publie ses correctifs. 4. Proposer une routine de suivi des vulnérabilités : sources consultées, fréquence, responsable nommé, délai d’examen. 5. Quand une faille est annoncée, croiser son périmètre avec l’inventaire de chaque version livrée et lister les clients concernés, sans conclure à l’exploitation. 6. Terminer par les décisions qui restent humaines : corriger, retirer, prévenir le client, déclencher le signalement. ## Lignes rouges - Ne jamais inscrire une version, une licence ou un fournisseur non lu dans une source. - Ne jamais déclarer un produit « non affecté » sans croisement avec l’inventaire de la version livrée. - Ne jamais coller dans un outil externe des secrets, clés ou fichiers de configuration de production. - Ne jamais décider seul d’un signalement ou d’une communication au client. ## Ce que la Skill ne fait pas Elle n’analyse pas le code à la recherche de failles et ne remplace ni l’outil de gestion des dépendances, ni le responsable sécurité, ni l’avis d’un juriste sur les obligations du fabricant. ## Modèle de sortie ~~~ PRODUIT / VERSION LIVRÉE : ... SOURCES LUES : ... INVENTAIRE - bibliothèques : nom, version, origine, licence - modèles et services d’IA : fournisseur, version, mode - inconnus à lever : ... SUIVI DES VULNÉRABILITÉS : sources, fréquence, responsable FAILLE ANNONCÉE : versions et clients concernés DÉCISIONS HUMAINES : ... ~~~

Copier le SKILL.md

--- name: tech-signalement-sous-24-heures description: Prépare à froid puis accompagne à chaud l’alerte précoce que le fabricant doit émettre au plus tard 24 heures après avoir connaissance d’une vulnérabilité activement exploitée ou d’un incident grave, obligation applicable depuis le 11 septembre 2026. À utiliser pour écrire la procédure, les rôles et les modèles, et le jour où une faille exploitée est découverte. --- # Alerter sous 24 heures sur une faille exploitée ou un incident grave ## Quand s’en servir Écrire la procédure d’alerte de l’éditeur ou de l’équipe produit. Préparer l’astreinte et les modèles de message. Le jour même, quand une vulnérabilité est exploitée dans un produit diffusé, ou qu’un incident grave touche sa sécurité. ## Ce que l’assistant doit savoir L’article 14 du règlement (UE) 2024/2847 impose une alerte précoce au plus tard 24 heures après la prise de connaissance d’une vulnérabilité activement exploitée ou d’un incident grave ; il s’applique depuis le 11 septembre 2026. Le délai court à partir de la connaissance, pas de la fin de l’analyse : il faut donc savoir qui, dans l’entreprise, « a connaissance », et le noter. Les destinataires, le canal et les notifications qui suivent l’alerte se vérifient sur la page Réglementation de wiikiiaii.com, tenue à jour. Si des données personnelles sont touchées, un second délai court en parallèle : notification à l’autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard (RGPD, article 33), avec documentation de toute violation (article 33 §5). Les clauses de notification des contrats clients s’ajoutent. L’assistant rédige et chronomètre ; il n’envoie rien et ne qualifie pas à la place du responsable. ## Marche à suivre 1. À froid, demander : qui décide de la qualification, qui envoie l’alerte, qui a les accès au canal de notification, qui remplace chacun la nuit et le week-end. Produire la fiche de rôles et un modèle d’alerte prérempli. 2. À la détection, faire noter l’heure exacte de prise de connaissance et calculer l’échéance des 24 heures. 3. Poser les questions de qualification (exploitation active constatée ou seulement possible, produits et versions touchés, impact sur la sécurité) et laisser le responsable trancher. 4. Rédiger l’alerte avec les seuls faits établis, sans attendre l’analyse complète, en marquant ce qui est inconnu. 5. Si des données personnelles sont en jeu, ouvrir en parallèle la Skill donnees-parties-dans-un-outil. 6. Préparer, sans l’envoyer, l’information des clients et utilisateurs, et la liste des contrats qui imposent un délai propre. 7. Tenir la chronologie horodatée, puis organiser le retour d’expérience. ## Lignes rouges - Ne jamais envoyer l’alerte ni un message client : l’assistant prépare, le responsable envoie. - Ne jamais recevoir le code d’exploitation, les charges ou les secrets compromis : travailler sur une description générale. - Ne jamais proposer de requalifier un incident pour échapper au délai. - Ne jamais avancer une cause ou un auteur dans l’alerte sans élément établi. ## Ce que la Skill ne fait pas Elle ne corrige pas la faille, ne mène pas l’investigation et ne remplace pas l’équipe de réponse à incident. ## Modèle de sortie ~~~ PRISE DE CONNAISSANCE : (date, heure, par qui) ÉCHÉANCE ALERTE : (date, heure) QUALIFICATION PROPOSÉE : vulnérabilité exploitée / incident grave / à confirmer DÉCIDÉE PAR : ... PRODUITS ET VERSIONS : ... FAITS ÉTABLIS - ... INCONNUS À CE STADE - ... DONNÉES PERSONNELLES : oui / non / à vérifier (délai 72 heures) CHRONOLOGIE - (heure) ... ~~~