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