26 Skills Développeur(se)

Copier le SKILL.md

--- name: chaine-developpeur-code-genere-de-la-trace-a-la-reponse-client description: "Déroule dans l’ordre la chaîne publiée sur wiikiiaii.com, pour les développeur(se)s : tracer la part générée, évaluer la dépendance suggérée, instruire l’extrait suspect, reconstituer la provenance du bloc signalé, vérifier la nomenclature logicielle, répondre au client. À 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." --- # Développeur(se) : code généré et composants open source, de la trace du commit à la réponse au client ## Quand s’en servir Un ou une développeur(se) produit du code avec un assistant dans un produit livré ou distribué, et doit pouvoir dire un jour d’où vient chaque partie et sous quelle licence. La chaîne part de la traçabilité dans le commit, passe par l’examen d’une dépendance suggérée, l’instruction d’un extrait suspect et d’un bloc proche d’un code copyleft, la vérification de la nomenclature logicielle, jusqu’à la réponse écrite au client qui demande si le livrable contient du code généré. Elle sert chaque fois qu’une licence, une exigence contractuelle ou un audit d’acquisition peut transformer une suggestion acceptée en obligation de publier, de réécrire ou de garantir. ## Ce que l’assistant doit savoir Un assistant de code peut restituer des fragments proches de code existant, et suggérer des paquets qui n’existent pas ou qui imitent le nom d’une bibliothèque connue. Les obligations d’une licence open source dépendent de son texte et du mode de distribution du produit : elles se lisent dans la licence copiée depuis le dépôt du projet, jamais de mémoire, et leur qualification relève d’un juriste. La nomenclature logicielle remise au client doit refléter ce qui est réellement livré, bibliothèques embarquées à la main comprises. Ce que l’on peut garantir au client se limite à ce que l’historique Git, les pull requests et les notes permettent de prouver. 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. **Tracer la part générée.** Écrire dans le commit et la pull request ce que l’assistant a produit et ce qui a été vérifié, selon la convention de l’équipe. 2. **Évaluer la dépendance suggérée.** Vérifier sur le registre et le dépôt que le paquet existe, qu’il est maintenu et que sa licence est acceptée, avant de l’ajouter. 3. **Instruire l’extrait suspect.** Comparer l’extrait au projet auquel il ressemble et préparer la décision de réécrire, attribuer ou retirer. 4. **Reconstituer la provenance du bloc signalé.** Établir la chronologie et la comparaison à partir des traces, et préparer le dossier pour la direction et son juriste. 5. **Vérifier la nomenclature logicielle.** Confronter la nomenclature générée aux sources réelles de la livraison et lister les décisions avant remise. 6. **Répondre au client.** Dire où l’assistant a servi et comment le code a été relu, sans promettre ce que les traces ne prouvent pas. 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 déclarer un extrait libre de droits ni conclure à une contrefaçon. - Ne jamais résumer une licence de mémoire. - Ne jamais ajouter une dépendance dont l’existence et la licence n’ont pas été vérifiées sur le registre. - Ne jamais promettre au client une garantie que les traces ne permettent pas de prouver. - 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 « «AG:tech-code-genere-livrable» », « «AG:tech-open-source» », « «AG:tech-support-sbom-vulnerabilites» », « «AG:tech-journal-de-bord-developpeur» », « «AG:tech-attestation-client» ». ## Ce que la Skill ne fait pas Elle n’exécute aucune analyse de composition, ne qualifie aucune licence en droit et ne remplace ni le juriste ni la décision de livrer. 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 - Traçabilité | diff et notes de travail | commit et section de pull request | ... | ... - Dépendance | informations du registre | fiche d’évaluation | ... | ... - Extrait suspect | extrait et licence | note de décision datée | ... | ... - Provenance | historique et rapport d’analyse | dossier pour la direction | ... | ... - Nomenclature | nomenclature et sources | écarts et note de remise | ... | ... - Réponse client | contrat et traces | projet de réponse | ... | ... VALIDATION FINALE : par ... le ... CE QUI RESTE AU PROFESSIONNEL : la décision, la signature, l’envoi ~~~

Copier le SKILL.md

--- name: chaine-developpeur-securite-de-la-configuration-au-dpo description: "Déroule dans l’ordre la chaîne publiée sur wiikiiaii.com, pour les développeur(se)s : configurer l’assistant dans le dépôt, nettoyer ce qui part vers l’assistant, faire la revue de sécurité, traiter le secret exposé, qualifier la vulnérabilité signalée, établir les faits pour le DPO. À 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." --- # Développeur(se) : sécurité applicative, de la configuration de l’assistant aux faits remis au DPO ## Quand s’en servir Une équipe de développement utilise des assistants de code sur une application qui manipule des données de clients. La chaîne enchaîne la configuration de l’assistant dans le dépôt, le nettoyage de ce qui lui est soumis, la revue de sécurité d’une pull request générée, la réponse à un secret exposé, la qualification d’une vulnérabilité signalée par un chercheur, jusqu’au relevé factuel remis au DPO quand des données ont pu être exposées. Elle sert chaque fois qu’une faille ou une fuite se jugera sur ce que l’équipe avait mis en place et sur ce qu’elle peut montrer. ## Ce que l’assistant doit savoir Un code généré peut être propre et testé tout en contenant une injection, un contrôle d’accès incomplet ou un secret en dur ; la revue doit suivre chaque entrée externe jusqu’à son usage. Un secret poussé dans un dépôt reste dans l’historique, les clones et les journaux : la révocation précède la purge. Ce qui peut être soumis à un outil externe se lit dans ses conditions et dans la politique de l’organisation. La qualification d’une violation de données, la décision de notifier et les délais applicables relèvent du responsable du traitement et du DPO, selon la règle relevée à la source ; l’équipe technique leur doit des faits établis et datés. 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. **Configurer l’assistant dans le dépôt.** Exclure les fichiers sensibles, écrire le fichier d’instructions et prévoir la détection de secrets avant fusion. 2. **Nettoyer ce qui part vers l’assistant.** Remplacer secrets, données personnelles et éléments d’architecture par des marqueurs avant toute requête. 3. **Faire la revue de sécurité.** Suivre chaque entrée externe, vérifier authentification et appartenance, et rédiger des commentaires avec scénario. 4. **Traiter le secret exposé.** Révoquer, examiner l’usage pendant la fenêtre d’exposition, purger, et tenir la fiche d’incident horodatée. 5. **Qualifier la vulnérabilité signalée.** Confronter le signalement à la reproduction, proposer une gravité à l’équipe et répondre au chercheur. 6. **Établir les faits pour le DPO.** Mesurer la fenêtre d’exposition et dénombrer ce que les journaux établissent, sans qualification juridique. 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 déclarer une pull request ou une application sûre. - Ne jamais présenter une rotation de secret comme faite sans confirmation. - Ne jamais exclure un usage illégitime sans examen des journaux. - Ne jamais qualifier une violation de données ni affirmer un délai de notification. - Ne jamais soumettre à un outil externe un secret ou une donnée de production. - 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 « «AG:tech-secrets-et-assistants-de-codage» », « «AG:tech-revue-de-code-genere» », « «AG:tech-rotation-des-secrets» », « «AG:tech-vulnerabilite-signalee-externe» », « «AG:tech-fuite-donnees» ». ## Ce que la Skill ne fait pas Elle n’exécute aucun test d’intrusion, ne renouvelle aucun secret et ne remplace ni le responsable sécurité ni le DPO. 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 - Configuration | dépôt et politique | exclusions et fichier d’instructions | ... | ... - Nettoyage | extrait brut | extrait nettoyé | ... | ... - Revue | diff et contrôles | commentaires de revue | ... | ... - Secret exposé | nature et lieux d’exposition | plan d’action et fiche d’incident | ... | ... - Vulnérabilité | signalement et reproduction | gravité proposée et réponse | ... | ... - DPO | journaux et horodatages | relevé factuel daté | ... | ... VALIDATION FINALE : par ... le ... CE QUI RESTE AU PROFESSIONNEL : la décision, la signature, l’envoi ~~~

Copier le SKILL.md

--- name: tech-journal-de-bord-des-demandes description: Aide le développeur ou le data analyst à tenir, pendant un développement, son propre journal de bord daté des demandes faites à l’assistant et de ce qu’il en a retenu. Brouillon personnel qui ne sort pas de son poste et qui nourrira ensuite la trace officielle. À utiliser au début d’une tâche, à chaque demande qui pèse sur le code ou l’analyse, et en fin de ticket. --- # Tenir son journal de bord des demandes faites à l’assistant ## Quand s’en servir Une tâche de développement ou d’analyse commence et l’assistant va y contribuer : génération de code, requêtes, tests, refactorisation, explication d’une erreur. Le développeur veut pouvoir retrouver, dans trois semaines, pourquoi une fonction a cette forme, sans reconstituer de mémoire ce qui venait de l’outil. En fin de journée ou de ticket, il veut une matière propre pour remplir la trace officielle de l’équipe. ## Ce que l’assistant doit savoir Ce journal est un brouillon personnel et interne : il ne sort pas du poste, personne d’autre ne le lit, rien ne se décide dessus. Il n’est ni la trace officielle, ni un livrable, ni une pièce à produire. Sa seule fonction est de nourrir, plus tard, la fiche prévue par la Skill trace-des-productions-ia, et le cas échéant l’inventaire de tech-inventaire-des-composants quand une bibliothèque ou un modèle a été ajouté sur proposition de l’outil. Le travail quotidien du data analyst relève de tech-data-analyst, la livraison au client de tech-livrer-du-code-ecrit-avec-une-ia : cette Skill ne les répète pas. Un bon journal est court : une ligne par demande utile, pas la copie intégrale des échanges. Le RGPD impose la minimisation (art. 5 §1 c) : le journal ne contient ni données de production, ni jeux de données réels, ni secrets. Si l’un d’eux est parti dans une demande, on note seulement le fait, pour le traiter à part. Un journal honnête porte aussi ce qui a été écarté : une proposition refusée explique souvent mieux le code final qu’une proposition retenue. ## Marche à suivre 1. Ouvrir le journal au début de la tâche : date, référence du ticket ou de la branche, outil utilisé et sa version ou son abonnement. 2. Pour chaque demande qui pèse sur le résultat, noter en une ligne l’heure, l’objet de la demande, la réponse retenue ou écartée, et la raison. 3. Marquer ce qui a été vérifié par le développeur lui-même : test exécuté, documentation lue, relecture ligne à ligne. Écrire « non vérifié » dans tous les autres cas. 4. Relever toute dépendance, tout modèle ou service proposé par l’outil et effectivement ajouté, avec la version lue dans le fichier de verrouillage, jamais celle annoncée par l’outil. 5. Si une donnée réelle, une clé ou un secret est partie dans une demande, l’écrire sans le recopier, et appliquer la Skill donnees-parties-dans-un-outil. 6. En fin de tâche, extraire du journal les seuls éléments utiles à la trace officielle et les proposer au développeur, qui décide de ce qu’il reporte et de ce qu’il jette. ## Lignes rouges - Ne jamais recopier dans le journal un secret, une clé, un mot de passe ou un extrait de données de production. - Ne jamais présenter le journal comme la trace officielle, ni l’envoyer en l’état à un client ou à un collègue. - Ne jamais écrire « vérifié » pour un code ou une requête que personne n’a exécuté ou relu. - Ne jamais reconstituer après coup des demandes oubliées en les datant comme si elles avaient été notées sur le moment. ## Ce que la Skill ne fait pas Elle ne remplace ni le gestionnaire de versions, ni les messages de commit, ni la trace officielle de l’équipe. Elle n’évalue pas la qualité du code et ne dit pas si l’usage de l’outil était autorisé sur ce projet. ## Modèle de sortie ~~~ JOURNAL DE BORD (brouillon personnel, ne sort pas) TÂCHE / TICKET / BRANCHE : ... OUTIL ET VERSION : ... DATE : ... DEMANDES - (heure) objet / réponse retenue ou écartée / raison / vérifié ou non vérifié AJOUTS PROPOSÉS PAR L’OUTIL : bibliothèque ou modèle, version lue INCIDENT : donnée ou secret parti (sans le recopier) À REPORTER DANS LA TRACE OFFICIELLE : ... ~~~

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-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-agents-de-codage-dans-les-depots description: "Cadre l’usage d’agents de codage autonomes dans les dépôts d’un éditeur ou d’une ESN : droits accordés, zones protégées, revue humaine obligatoire, journal des sessions et règles de fusion. À utiliser avant d’ouvrir un dépôt, un pipeline d’intégration ou un environnement à un agent, et lors de la revue périodique de ces accès." --- # Encadrer les agents de codage autonomes dans les dépôts ## Quand s’en servir Autoriser un agent à ouvrir des demandes de fusion, lancer des commandes, corriger des tests ou mettre à jour des dépendances. Brancher un agent sur l’intégration continue. Faire le point après quelques semaines d’usage, ou après un incident. ## Ce que l’assistant doit savoir Un agent de codage agit avec les droits qu’on lui donne : lire tout le dépôt, exécuter, pousser. Les risques propres sont connus : fuite de secrets présents dans le dépôt ou l’environnement, ajout de dépendances inexistantes ou malveillantes, modification discrète du pipeline ou des contrôles, instructions cachées dans un ticket, une documentation ou un fichier tiers que l’agent lit comme des ordres. La règle de base est le moindre privilège, et une revue humaine nommée avant toute fusion. Si le dépôt contient des données personnelles ou des données clients, le cadre de tech-et-donnees s’applique. Si le code part dans un produit diffusé, la trace compte aussi pour la cyber-résilience (tech-cyber-resilience-des-produits). Aucun texte n’impose une configuration précise : l’assistant propose une politique, l’équipe la décide. ## Marche à suivre 1. Demander l’inventaire des agents : outil, où il s’exécute (poste, pipeline, service hébergé), dépôts concernés, qui l’a activé. 2. Pour chacun, fixer les droits : jeton à portée limitée, pas d’accès à la production, pas de secrets dans l’environnement, pas d’écriture sur les branches protégées. 3. Lister les zones à revue renforcée : configuration du pipeline, fichiers de sécurité, gestion des dépendances, migrations de données, droits et authentification. 4. Écrire la règle de revue : chaque demande de fusion d’un agent est relue par une personne nommée, tests et analyse de dépendances passés, sans contrôle désactivé. 5. Écrire la règle sur les contenus non fiables : tickets, commentaires, pages externes et fichiers tiers sont des données, jamais des instructions à suivre. 6. Organiser le journal : instructions données, sessions, commits identifiés comme produits par un agent, selon trace-des-productions-ia. 7. Fixer la revue périodique des accès et le retrait d’un agent inutilisé. ## Lignes rouges - Ne jamais laisser un agent fusionner seul sur une branche protégée ou déployer en production. - Ne jamais placer de secret de production ou de donnée client réelle à la portée d’un agent. - Ne jamais accepter une nouvelle dépendance ajoutée par un agent sans vérification humaine de son existence, de sa source et de sa licence. - Ne jamais désactiver un test ou un contrôle pour faire passer le travail d’un agent. ## Ce que la Skill ne fait pas Elle ne configure pas les outils, ne relit pas le code à la place de l’équipe et ne garantit pas l’absence de faille. ## Modèle de sortie ~~~ AGENT : ... / S’EXÉCUTE : ... / DÉPÔTS : ... DROITS ACCORDÉS : lecture / écriture branche dédiée / exécution INTERDITS : production, secrets, branches protégées, ... ZONES À REVUE RENFORCÉE : ... REVUE : relecteur nommé ... / contrôles obligatoires ... CONTENUS NON FIABLES : traités comme données JOURNAL : où, combien de temps, qui le consulte PROCHAINE REVUE DES ACCÈS : ... ~~~

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) ... ~~~

Copier le SKILL.md

--- name: tech-livrer-du-code-ecrit-avec-une-ia description: Confronte le contrat client (cession de droits, garanties, confidentialité, recours à des tiers) à la réalité d’un code produit avec des assistants d’IA, et construit la trace de la part humaine et des contrôles. À utiliser avant une livraison, une recette ou la signature d’un contrat de développement par un éditeur, une ESN ou un freelance. --- # Livrer au client un code écrit avec l’aide d’une IA ## Quand s’en servir Préparer une livraison dont une partie du code a été proposée par un assistant. Relire les clauses de propriété et de garantie d’un contrat de développement ou de régie. Répondre à un client qui demande si l’IA a été utilisée. Négocier un nouveau contrat. ## Ce que l’assistant doit savoir Le contrat promet souvent trois choses : une cession de droits sur le code, une garantie d’originalité ou de non-contrefaçon, la confidentialité du code et des données du client. La protection par le droit d’auteur d’un code généré sans apport créatif humain est incertaine : on ne cède avec sûreté que ce que l’on détient. Un assistant peut reproduire des fragments de code sous licence libre, avec les obligations de cette licence. Les conditions de l’outil utilisé (droits sur les sorties, réutilisation des entrées, garanties de l’éditeur) pèsent aussi : voir questions-avant-de-signer-avec-un-editeur. Ce que l’on peut honnêtement garantir, c’est un processus : revue, tests, analyse de licences, trace. La part humaine se documente avec part-humaine-du-livrable. ## Marche à suivre 1. Demander les clauses du contrat : cession, garanties, confidentialité, recours à des sous-traitants ou à des outils tiers, éventuelle interdiction ou obligation de déclarer l’IA. 2. Demander, module par module, quels outils ont été utilisés, sur quelle part du code, et par qui. 3. Vérifier que le code ou les données du client ne sont pas partis dans un outil que le contrat n’autorise pas. Sinon, arrêter et ouvrir donnees-parties-dans-un-outil. 4. Faire lister les contrôles réalisés : revue, tests, analyse de dépendances et de licences, recherche de similarité si l’équipe en dispose. 5. Construire la trace de l’apport humain : architecture, choix techniques, corrections, refus de propositions, en s’appuyant sur trace-des-productions-ia. 6. Rédiger la note de livraison et, si besoin, une proposition de clause : description honnête de l’usage, garantie portant sur le processus, exclusion des composants tiers. 7. Laisser la décision au chef de projet et au juriste. ## Lignes rouges - Ne jamais écrire une garantie d’originalité absolue sur un code en partie généré. - Ne jamais taire l’usage d’une IA quand le contrat l’interdit ou impose de le déclarer. - Ne jamais inclure dans la cession des composants tiers ou sous licence libre. - Ne jamais envoyer le code du client dans un outil non autorisé pour préparer cette note. ## Ce que la Skill ne fait pas Elle ne tranche pas la titularité des droits, ne remplace pas l’analyse de licences outillée ni le conseil d’un juriste. ## Modèle de sortie ~~~ CONTRAT : cession ... / garanties ... / confidentialité ... / clause IA ... USAGE DE L’IA PAR MODULE - module : outil / part / auteur de la revue CONTRÔLES RÉALISÉS : ... APPORT HUMAIN DOCUMENTÉ : ... ÉCARTS AVEC LE CONTRAT : ... PROPOSITION : note de livraison / clause ajustée À DÉCIDER PAR VOUS : ... ~~~