Articles
Des articles, à partir de nos propres données
Nous publions ce que nous pouvons montrer. Chaque article ci-dessous repose sur un jeu de données que nous tenons et citons, et là où vous pouvez relancer la requête vous-même, nous disons comment.
L'analyse d'impact d'un système d'IA ISO 42001 : ce que l'article 6.1.4 demande, les trois niveaux de conséquences, où elle rencontre le règlement sur l'IA, les erreurs qu'un auditeur relève, et une page qui la rédige
L'article 6.1.4 de l'ISO/IEC 42001 fait évaluer par l'entreprise ce que chaque système d'IA pourrait faire aux individus et aux groupes qu'il touche et à la société, conserver le résultat comme information documentée et agir en conséquence tout au long du cycle de vie du système ; l'article 8.4 exécute le processus et quatre mesures de l'annexe A demandent le processus, la conservation, le préjudice pour les individus et les groupes, et le préjudice au-delà des utilisateurs. C'est l'enregistrement que la norme a et que l'ISO 27001 n'a pas. Une analyse qu'un auditeur accepte nomme la finalité et le mauvais usage prévisible, les personnes, les conséquences aux trois niveaux avec une vraisemblance et une gravité chacune, les bénéfices, les mesures, un résultat et une date de revue ; au regard du règlement sur l'IA, elle est l'entrée de l'analyse d'impact sur les droits fondamentaux de l'article 27 et le lieu où l'entreprise enregistre sa propre lecture du système. Une page gratuite la rédige pour un système.
13 septembre 2026
L'appréciation des risques ISO 27001 pour une entreprise de logiciels : ce que l'article 6.1.2 demande, une méthode à cinq points, les risques de départ, et une page qui rédige le registre et le plan de traitement
L'article 6.1.2 ne prescrit pas de méthode ; il prescrit ce que la méthode doit produire : des critères d'acceptation et d'appréciation des risques, une identification des risques de sécurité de l'information, une analyse de leurs conséquences et de leur vraisemblance, une évaluation au regard des critères, et des résultats reproductibles et comparables. L'article 6.1.3 demande ensuite les options de traitement, les mesures, la comparaison avec l'annexe A, la déclaration d'applicabilité et le plan. Pour une entreprise de logiciels, les risques sont largement connus avant le premier atelier : compromission d'identifiants, ordinateur portable perdu, panne d'un fournisseur cloud, sauvegarde qui ne se restaure pas, employé parti dont l'accès reste ouvert, vulnérabilité livrée dans son propre code. Une échelle à cinq points pour la vraisemblance et l'impact, le produit comme niveau, un seuil d'acceptation, l'option de traitement et les mesures pour chaque risque au-dessus, et une page gratuite qui rédige le registre et le plan en six langues.
13 septembre 2026
L'article 13 du CRA pour un fabricant de logiciels : les vingt-cinq paragraphes dans l'ordre, lesquels sont les vôtres, lesquels ceux de la Commission, et une liste de contrôle par rôle
L'article 13 du Cyber Resilience Act est l'article du fabricant : vingt-cinq paragraphes, des exigences essentielles du paragraphe 1 aux pouvoirs de la Commission du paragraphe 25. Vingt et un d'entre eux sont des obligations qu'un fabricant de logiciels porte, de l'évaluation des risques du produit et de la diligence sur les composants à la période d'assistance, au point de contact unique, à la documentation technique conservée dix ans, aux mesures correctives et à ce qu'il faut faire avant de cesser ses activités ; deux sont des options, deux appartiennent à la Commission et aux autorités. L'article 14 ajoute les délais de notification, les articles 19 et 20 les obligations de l'importateur et du distributeur, l'article 24 celles du gestionnaire, et l'annexe I les exigences que le produit doit respecter. Une page gratuite liste chaque ligne qui lie votre rôle, dans les termes du Journal officiel en six langues, avec un statut par ligne.
13 septembre 2026
La fiche d'action corrective ISO 27001 : ce que l'article 10.2 demande après une non-conformité, les sept sections qu'un auditeur accepte, les erreurs qui rouvrent un constat, et une page qui la rédige
L'article 10.2 est ce qui arrive à une non-conformité une fois qu'elle est trouvée : la corriger et traiter ce qu'elle a causé, trouver la cause, demander si le même problème existe ailleurs, agir pour qu'elle ne se reproduise pas, vérifier que l'action a marché, modifier le système de management là où la cause se trouvait, et conserver la non-conformité, les actions et leurs résultats comme information documentée. Une fiche qu'un auditeur accepte a sept sections dans cet ordre, sépare la correction de l'action corrective et reste ouverte jusqu'à ce que la vérification montre que l'action a marché. Une page gratuite rédige la fiche à partir du constat, de la correction, de la cause, de l'action avec son responsable et sa date, et de la vérification de l'efficacité.
13 septembre 2026
La politique de sécurité de l'information ISO 27001 : ce que l'article 5.2 demande, les neuf sections d'une politique courte, les erreurs qu'un auditeur relève, et une page qui la rédige
L'article 5.2 demande à la direction une politique adaptée à la finalité de l'entreprise, qui porte les objectifs de sécurité ou le cadre pour les fixer, s'engage sur les exigences applicables et sur l'amélioration du système, et est documentée, communiquée et disponible pour les parties qui en ont besoin. Cela fait sept choses, dont aucune n'est un nombre de pages. Une bonne politique pour une entreprise de logiciels tient en deux pages en neuf sections : finalité, périmètre, pourquoi la sécurité compte ici, engagements, objectifs, rôles, les politiques thématiques en dessous, conformité, et communication et revue. Les erreurs qu'un auditeur relève sont le modèle avec le nom d'une autre entreprise, les trente pages que personne n'a lues, l'approbation manquante, des objectifs que personne ne peut mesurer et une politique qu'aucun nouvel arrivant n'a vue. Une page gratuite rédige la politique à partir de dix réponses en six langues.
13 septembre 2026
La politique IA ISO 42001 pour une entreprise de logiciels : ce que l'article 5.2 demande, les dix sections, les obligations du règlement sur l'IA qu'elle nomme, les erreurs qu'un auditeur relève, et une page qui la rédige
L'article 5.2 de l'ISO/IEC 42001 demande à la direction une politique IA adaptée à ce pour quoi l'entreprise utilise l'IA, qui donne le cadre des objectifs IA, s'engage sur les exigences applicables et sur l'amélioration du système, est documentée, communiquée et disponible, et dit comment elle se place à côté des autres politiques. Trois mesures de l'annexe A, A.2.2, A.2.3 et A.2.4, demandent la politique, son alignement avec les autres politiques et sa revue. Une politique IA courte pour une entreprise de logiciels tient en dix sections : finalité, périmètre, position, les usages exclus, responsabilité, objectifs, les exigences applicables, les autres politiques, communication et revue. La section des exigences est celle où entre le règlement sur l'IA : l'obligation de maîtrise de l'article 4, les obligations de transparence de l'article 50 lorsque l'entreprise génère du contenu, et une détermination consignée du haut risque par système, que la politique elle-même n'affirme jamais. Une page gratuite rédige la politique à partir de onze réponses en six langues.
13 septembre 2026
La revue de direction ISO 27001 : les sept éléments d'entrée de l'article 9.3 en ordre du jour, les quatre tendances, les deux éléments de sortie, ce que le compte rendu doit montrer, et une page qui le rédige
L'article 9.3 fait revoir par la direction le système de management à intervalles planifiés contre sept éléments d'entrée : les actions de la revue précédente, les changements dans les enjeux externes et internes, les changements dans ce que les parties intéressées ont besoin et attendent, le retour sur la performance avec ses quatre tendances (non-conformités et actions correctives, surveillance et mesurage, résultats d'audit, les objectifs), le retour des parties intéressées, l'appréciation des risques et le plan de traitement, et les opportunités d'amélioration. Les éléments de sortie sont deux : des décisions d'amélioration continue et tout changement dont le système a besoin, conservés comme information documentée. Le compte rendu qu'un auditeur accepte montre chaque élément d'entrée examiné et chaque décision prise, avec un responsable et une date sur chaque action. Une page gratuite rédige le compte rendu dans l'ordre de l'article à partir des faits de la réunion, des chiffres et de ce qui a été dit.
13 septembre 2026
Le Data Act pour une entreprise SaaS : les obligations de changement de fournisseur depuis le 12 septembre 2025, les neuf clauses contractuelles, la fin des frais de changement, et ce qu'un détenteur de données doit
Le règlement (UE) 2023/2854 s'applique depuis le 12 septembre 2025, et une entreprise qui vend du logiciel hébergé est, à ce titre, un fournisseur de service de traitement de données, quelle que soit sa taille. Le chapitre VI lui fait supprimer tout obstacle à ce qu'un client change de fournisseur ou rapatrie ses données sur site : un contrat écrit avec les neuf clauses de l'article 25, paragraphe 2, un préavis d'au plus deux mois, une période de transition d'au plus 30 jours civils, une période de récupération d'au moins 30 jours civils, l'effacement ensuite, un registre en ligne des données exportables, des interfaces ouvertes sans frais, une mention sur le site web de la juridiction dont relève l'infrastructure, et des frais de changement fondés sur les coûts aujourd'hui et interdits à partir du 12 janvier 2027. Une entreprise dont le produit est un produit connecté ou un service connexe est aussi un détenteur de données au titre du chapitre II, avec l'accès dès la conception pour les produits mis sur le marché après le 12 septembre 2026. Les 96 lignes du règlement qui lient chaque rôle sont un jeu de données en six langues.
13 septembre 2026
Le délai d'incident NIS2 pour une entreprise de logiciels : l'alerte précoce à 24 heures, la notification à 72 heures, le rapport final à un mois, ce qui rend un incident important pour un fournisseur cloud, et une page qui rédige les trois rapports
L'article 23, paragraphe 4, de NIS2 fait courir trois délais à partir du moment où une entité essentielle ou importante a connaissance d'un incident important : une alerte précoce dans les 24 heures, une notification d'incident dans les 72, et un rapport final dans le mois qui suit cette notification, avec un rapport intermédiaire sur demande et un rapport d'avancement lorsque l'incident est encore en cours. Pour un fournisseur de services d'informatique en nuage, le règlement d'exécution (UE) 2024/2690 dit quand un incident est important : une perte financière directe supérieure à 500 000 EUR ou à 5 % du chiffre d'affaires, le montant le plus bas étant retenu, un service totalement indisponible pendant plus de 30 minutes, une disponibilité limitée pour plus de 5 % ou 1 million de ses utilisateurs dans l'Union pendant plus d'une heure, ou une compromission des données soupçonnée d'être malveillante. Ce que chaque rapport contient, à quel CSIRT il va, et une page gratuite qui calcule les délais et rédige les trois en six langues.
13 septembre 2026
Ce qu'un déployeur d'un système d'IA à haut risque doit au titre de l'article 26 du règlement sur l'IA : les douze paragraphes dans l'ordre, l'analyse d'impact de l'article 27, quand vous devenez le fournisseur, et les enregistrements qu'un système ISO 42001 tient
La plupart des entreprises rencontreront le règlement sur l'IA en tant que déployeurs : elles achètent ou licencient un système que quelqu'un d'autre a construit et l'utilisent sous leur propre autorité. Pour un système à haut risque, les devoirs sont à l'article 26, douze paragraphes, inchangés par l'omnibus numérique, applicables à partir du 2 décembre 2027 pour les systèmes de l'annexe III. Chaque paragraphe lu dans l'ordre, l'analyse d'impact sur les droits fondamentaux de l'article 27 et qui la porte, les trois façons dont un déployeur devient le fournisseur au titre de l'article 25, le droit à l'explication de l'article 86, le plafond de l'article 99, et la mesure ISO 42001 qui produit chaque enregistrement.
12 septembre 2026
Ce que coûte une certification ISO 9001 : les jours d'audit que l'IAF MD 5 fixe par effectif, le taux journalier, le total sur trois ans, et pourquoi c'est un tiers de l'ISO 27001
Les organismes de certification ne publient pas de prix, mais les jours d'audit ne sont pas leur opinion : l'IAF MD 5 les fixe selon le nombre de personnes dans le périmètre, 1,5 jour jusqu'à cinq personnes, 3 pour 16 à 25, 7 pour 86 à 125, et l'organisme d'accréditation tient le certificateur au tableau. Multipliez par un taux journalier de 1 200 à 1 800 euros, ajoutez deux audits de surveillance d'environ un tiers chacun, et vous avez votre chiffre avant tout devis. Calculé pour six tailles d'entreprise, avec les jours ISO 27001 en regard, ce qui fait monter ou baisser le chiffre, et ce que vous payez d'autre.
12 septembre 2026
Comment vérifier qu'un certificat ISO 9001 est authentique : ce qu'un certificat doit montrer, trois vérifications en dix minutes, et les 27 registres d'accréditation
L'ISO ne certifie pas les entreprises et n'en tient aucun registre : un certificat ne vaut donc que par l'organisme qui l'a délivré et par l'accréditation derrière cet organisme. Ce que l'ISO/IEC 17021-1 fait figurer sur un certificat, les trois vérifications (le certificateur est accrédité pour l'ISO 9001, le certificat est en cours de validité, le périmètre couvre ce que vous achetez), les 27 registres nationaux d'accréditation avec leurs liens, pourquoi un certificateur d'un autre État de l'UE vaut celui du vôtre, et pourquoi le certificat non accrédité bon marché coûte plus cher à la fin.
12 septembre 2026
La politique DORA de votre banque envers ses prestataires, RTS 2024/1773 : les six questions de la diligence raisonnable, les cinq sources d'assurance, les huit conditions pour accepter votre certificat ISO 27001 à la place d'un audit, et les cinq rapports que vous devrez
Chaque entité financière de l'Union a une politique écrite sur ses contrats de services TIC soutenant des fonctions critiques ou importantes, et le règlement délégué (UE) 2024/1773 dit ce que cette politique doit contenir, en vigueur depuis le 15 juillet 2024. Lu du côté du prestataire : les six choses que le client évalue à votre sujet avant de signer (article 6), les cinq sources d'assurance qu'il peut utiliser et les huit conditions auxquelles il peut se fier à vos certifications ou rapports d'audit plutôt que de vous auditer lui-même (article 8), les indicateurs clés, les pénalités et les cinq types de rapport que le contrat exigera (article 9), et le plan de sortie qu'il doit tester (article 10). Avec ce qu'un certificat ISO 27001 répond, et ce qu'il ne répond pas.
12 septembre 2026
DORA pour un éditeur de logiciels : les clauses contractuelles de l'article 30 que votre client bancaire enverra, le registre d'informations où vous figurerez, et ce qu'ISO 27001 répond déjà
Depuis le 17 janvier 2025, chaque banque, assureur, entreprise d'investissement et établissement de paiement de l'Union gère ses éditeurs de logiciels au titre du règlement (UE) 2022/2554, DORA. L'éditeur n'est pas réglementé ; le contrat l'est. L'article 30 énumère neuf clauses que tout contrat de services TIC doit porter et six de plus lorsque le service soutient une fonction critique ou importante : lieux, restitution des données, assistance en cas d'incident à un coût fixé d'avance, coopération avec les autorités du client, préavis de résiliation, droits d'audit, stratégies de sortie. Chaque clause lue dans le règlement, le registre d'informations que le client dépose chaque année, les trois actes délégués derrière, et pour lesquelles de ces clauses un système ISO 27001 produit déjà la preuve.
12 septembre 2026
La sous-traitance sous DORA, RTS 2025/532 : les douze clauses que votre contrat porte quand vous sous-traitez un service critique, les dix conditions que votre client vérifie d'abord, et le délai de préavis avant de changer de sous-traitant
Depuis le 22 juillet 2025, une entité financière ne peut laisser son éditeur de logiciels sous-traiter un service soutenant une fonction critique ou importante qu'aux conditions du règlement délégué (UE) 2025/532. Dix conditions que le client évalue avant de signer, de votre capacité à identifier chaque sous-traitant à la question de savoir si le sous-traitant accorde les mêmes droits d'audit ; douze clauses que le contrat porte ensuite, de votre responsabilité pour le service du sous-traitant au droit de résiliation du client ; un délai de préavis pendant lequel vous ne pouvez pas changer de sous-traitant tant que le client n'a pas approuvé ou ne s'est pas abstenu d'objecter ; et trois cas dans lesquels le client peut résilier. Lu au Journal officiel, avec ce que le registre d'informations enregistre sur la chaîne et ce qu'un registre des fournisseurs ISO 27001 répond déjà.
12 septembre 2026
Les dix-neuf types de services TIC de DORA, S01 à S19 : lequel est un produit SaaS, ce que le registre d'informations enregistre à son sujet, et pourquoi un contrat peut devenir plusieurs lignes
Chaque service TIC qu'une banque, un assureur ou un établissement de paiement achète est enregistré dans son registre d'informations sous l'un de dix-neuf codes, S01 à S19, tirés de l'annexe III du règlement d'exécution (UE) 2024/2956. Un produit hébergé est S19, un logiciel installé S13, un service géré S14, un flux de données S05, et le client déclare une ligne par service et par fonction, de sorte qu'un seul contrat peut en devenir plusieurs. Les dix-neuf types avec les descriptions du règlement lui-même, la colonne qui porte le code, ce que le client doit enregistrer à côté, et pourquoi le code que vous donnez à un client doit correspondre à celui que vous donnez au suivant.
12 septembre 2026
Essentielle ou importante sous NIS2 : la règle de taille, les règles sans condition de taille et les sept manières d'être essentielle
Que NIS2 atteigne une entreprise, c'est l'article 2 ; qu'elle soit essentielle ou importante, c'est l'article 3 ; et la différence, c'est une supervision ex ante, un plafond d'amende plus élevé et une lecture plus stricte de tout le reste. Les deux articles cités, les classes de taille de la recommandation 2003/361/CE telles qu'on les compte vraiment, les règles qui ignorent la taille, et les cas qu'un éditeur de logiciels rate : un fournisseur de services en nuage de 40 salariés, un grand constructeur de machines, un bureau d'enregistrement, une entreprise hors de l'Union.
12 septembre 2026
ISO/IEC 27701:2025 pour une entreprise de logiciels : la norme autonome de protection de la vie privée, ses 78 mesures, ce qu'un système ISO 27001 couvre déjà, et les articles du RGPD que chaque mesure prouve
La deuxième édition de l'ISO/IEC 27701, publiée en octobre 2025, n'est plus une extension de l'ISO 27001 : c'est une norme de système de management à part entière, avec les articles 4 à 10 et une seule annexe A de 78 mesures, 31 pour les responsables du traitement de DCP, 18 pour les sous-traitants de DCP et 29 mesures de sécurité de l'information pour les deux. Lue ligne par ligne pour une entreprise de logiciels : lesquelles des 103 exigences un système ISO 27001 en fonctionnement couvre déjà à moitié et ce que 27701 demande au-delà, les 33 exigences de protection de la vie privée qu'aucune mesure de sécurité ne produit, et les 32 articles du RGPD que les mesures prouvent, du registre des traitements au délai de violation de 72 heures. La lecture de StandardOS, le texte de la norme restant où il est.
12 septembre 2026
Quels pays de l'UE citent l'ISO 9001 dans les marchés publics : 4 897 avis allemands, 4 743 roumains, et un avis roumain sur dix la cite
Sur 365 jours, l'ISO 9001 apparaît dans 16 356 avis TED d'acheteurs de l'UE-27, 1,87 % de tout ce qu'ils ont publié et cinq fois les 3 361 qui citent l'ISO 27001. L'Allemagne et la Roumanie représentent 59 % des mentions ; la Roumanie la cite dans 10,48 % de ses avis, la Bulgarie dans 7,34 %, la Hongrie dans 7,02 % ; la France, l'Espagne et l'Italie la citent à peine. Et 1 475 avis citent les deux normes, 44 % de chaque mention de l'ISO 27001. Le tableau par pays, le recoupement, et la requête pour les recalculer.
12 septembre 2026
ISO 9001 pour une entreprise de logiciels : ce que signifie le paragraphe 8 quand le produit est du code, sous-paragraphe par sous-paragraphe
Les paragraphes 4 à 7, 9 et 10 de l'ISO 9001:2015 sont le squelette de système de management qu'une entreprise ISO 27001 fait déjà tourner. Le paragraphe 8, Réalisation des activités opérationnelles, est celui écrit pour les usines et les centres de services, et celui qu'une entreprise de logiciels doit traduire. Ce qu'est chaque sous-paragraphe quand le produit est un logiciel : la revue des exigences avant de s'engager (8.2), le cycle de développement comme conception et développement (8.3), les fournisseurs cloud et les dépendances comme prestataires externes (8.4), le déploiement, la traçabilité, les données des clients et le support comme production et prestation de service (8.5), le portail de libération (8.6), et les bugs et incidents comme éléments de sortie non conformes (8.7). Avec les endroits où le Cyber Resilience Act demande les mêmes enregistrements.
12 septembre 2026
L'analyse d'impact RGPD pour une entreprise de logiciels : les trois cas de l'article 35, paragraphe 3, les neuf critères derrière eux, les quatre éléments de l'article 35, paragraphe 7, et une page qui la rédige
L'article 35 exige une analyse d'impact relative à la protection des données avant tout traitement susceptible d'engendrer un risque élevé, et nomme trois cas où elle est requise en tout état de cause. Quelles fonctionnalités d'un produit y tombent, les neuf critères qu'appliquent les autorités de contrôle et la règle selon laquelle deux d'entre eux signifient le plus souvent une analyse, les listes que les autorités publient au titre de l'article 35, paragraphes 4 et 5, les quatre éléments que l'analyse doit contenir, l'avis du délégué à la protection des données et l'avis des personnes concernées, la consultation préalable de l'article 36 avec ses huit semaines, et le réexamen quand le risque change. Avec la page gratuite qui décide si une analyse est due et la rédige.
12 septembre 2026
L'article 20 de NIS2 pour la direction : ce que l'organe de direction doit approuver, superviser et apprendre, les douze endroits où le règlement d'exécution le nomme, et ce que signifie la responsabilité
L'article 20 de NIS2 impose à l'organe de direction d'une entité essentielle ou importante d'approuver les mesures de gestion des risques en matière de cybersécurité, d'en superviser la mise en œuvre, de pouvoir être tenu responsable des violations de l'article 21 par l'entité, et de suivre une formation. Le règlement d'exécution 2024/2690 nomme ensuite l'organe de direction à douze endroits de son annexe : une approbation datée de la politique, un réexamen annuel, une ligne de rapport directe, l'acceptation des risques résiduels, des rapports de conformité, un programme de sensibilisation. Chacun des douze comme enregistrement, la clause d'ISO 27001 qui le produit déjà, et ce que les articles 32 et 34 disent de la responsabilité.
12 septembre 2026
L'article 50 du règlement sur l'IA pour une entreprise qui livre ou utilise de l'IA générative : les quatre obligations de transparence en vigueur depuis le 2 août 2026, la transition du 2 décembre 2026, le code de bonnes pratiques et l'icône UE
L'article 50 est l'obligation du règlement sur l'IA qui atteint une entreprise que son système soit à haut risque ou non : dire aux gens qu'ils parlent à une IA, marquer les contenus générés pour que des machines les détectent, divulguer les hypertrucages et les textes écrits par l'IA sur des questions d'intérêt public, informer les personnes exposées à la reconnaissance des émotions. Il s'applique depuis le 2 août 2026, l'omnibus numérique l'a laissé inchangé et a donné aux fournisseurs de systèmes génératifs déjà sur le marché jusqu'au 2 décembre 2026 pour l'obligation de marquage. Les quatre paragraphes dans l'ordre, qui est fournisseur et qui est déployeur pour chacun, le code de bonnes pratiques de la Commission du 10 juin 2026 avec son marquage à deux couches et son icône AI, l'amende, et l'enregistrement qu'un système ISO 42001 tient.
12 septembre 2026
L'enregistrement NIS2 : les deux listes sur lesquelles vous pouvez figurer, ce que vous communiquez, pour quand et à qui (article 3(4) et article 27)
NIS2 prévoit deux enregistrements, pas un. Chaque entité essentielle ou importante communique quatre informations à son autorité compétente pour que l'État membre puisse établir sa liste au plus tard le 17 avril 2025 (article 3(3) et (4)), les modifications étant notifiées sous deux semaines. Onze types d'entités numériques, dont les fournisseurs de services en nuage et les fournisseurs de services gérés, communiquent aussi six informations au plus tard le 17 janvier 2025 pour le registre de l'ENISA (article 27), les modifications sous trois mois. Quel État les reçoit (article 26), à quoi servent les deux listes, ce que l'enregistrement ne décide pas, et l'enregistrement à conserver.
12 septembre 2026
L'ISO 9001:2015 exige-t-elle un manuel qualité ? Ce que le paragraphe 7.5 demande à la place, les 21 endroits où la norme nomme l'information documentée, et à quoi sert un manuel aujourd'hui
L'ISO 9001:2008 exigeait un manuel qualité ; l'ISO 9001:2015 ne l'exige pas, et le dit dans son annexe A. Ce qu'elle exige, c'est de l'information documentée : cinq choses à tenir à jour (le domaine d'application, l'information sur les processus, la politique qualité, les objectifs, la planification opérationnelle) et seize sortes d'enregistrements à conserver, chacune nommée par paragraphe. Ce que le paragraphe 7.5 demande de chaque document, pourquoi un manuel reste le bon endroit pour la carte du système, et ce qu'il faut y mettre. Avec le nombre d'avis de marché de l'UE qui ont demandé l'ISO 9001 l'an dernier, 17 076, cinq fois l'ISO 27001.
12 septembre 2026
La déclaration d'applicabilité ISO 27001 pour une entreprise de logiciels : les 93 mesures, les quatre colonnes de l'article 6.1.3 d), les exclusions qu'un auditeur accepte, et une page qui la rédige
La déclaration d'applicabilité est le seul document ISO 27001 qu'un auditeur lit avant tout le reste, et l'article 6.1.3 d) en fait quatre questions par mesure : est-elle nécessaire, pourquoi est-elle incluse, est-elle mise en œuvre, et pourquoi une mesure de l'annexe A est-elle laissée de côté. Pour une entreprise de logiciels sans bureaux propres et avec une pile hébergée, les 93 mesures de l'édition 2022 se répartissent entre celles qui s'appliquent en entier, la poignée honnêtement exclue, et celles partiellement mises en œuvre qui décident des constats de l'audit. Ce que chaque colonne signifie, les exclusions qu'un auditeur accepte et celles qu'il n'accepte jamais, comment la déclaration suit le plan de traitement des risques, et une page gratuite qui la rédige en six langues avec les statuts dans l'adresse.
12 septembre 2026
La déclaration UE de conformité au titre du CRA : l'annexe V point par point, la forme simplifiée et un exemple rempli
L'article 28 impose au fabricant d'établir une déclaration UE de conformité avant la mise sur le marché, selon le modèle de l'annexe V, et l'article 28(4) fait de sa signature l'acte par lequel le fabricant assume la responsabilité du produit. Les huit points de l'annexe V, la forme simplifiée en une phrase de l'annexe VI, les règles qui l'entourent (langues, la déclaration unique, les familles de produits, 10 ans de conservation), un exemple rempli, et ce que coûte une déclaration absente ou incorrecte au titre des articles 58 et 64.
12 septembre 2026
La demande d'une personne concernée RGPD pour une entreprise de logiciels : le mois de l'article 12, paragraphe 3, les huit informations d'une réponse d'accès, les deux mois supplémentaires et une page qui calcule le délai
Une demande au titre des articles 15 à 22 reçoit une réponse dans les meilleurs délais et en tout état de cause dans un délai d'un mois à compter de la réception (article 12, paragraphe 3) ; le délai expire à la même date du mois suivant ou le dernier jour de celui-ci ; deux mois supplémentaires sont disponibles lorsque les demandes sont complexes ou nombreuses, la personne concernée étant informée dans le premier mois ; un refus porte ses motifs et les voies de recours dans le même mois (12, paragraphe 4) ; la réponse est gratuite sauf demande manifestement infondée ou excessive, et l'entreprise en supporte la charge de la preuve (12, paragraphe 5). Une demande d'accès reçoit une copie des données et les huit informations de l'article 15, paragraphe 1, points a) à h), des finalités à la prise de décision automatisée. Lu au regard du catalogue, avec une page gratuite qui calcule le délai et rédige la réponse en six langues.
12 septembre 2026
La maîtrise de l'IA au titre de l'article 4 du règlement sur l'IA, tel que réécrit le 27 juillet 2026 : ce que « prendre des mesures » signifie, qui est couvert, ce qui n'est pas exigé, et l'enregistrement à tenir
L'article 4 s'applique à tout fournisseur et déployeur d'un système d'IA depuis le 2 février 2025. L'omnibus numérique l'a réécrit : des mesures pour favoriser le développement de la maîtrise de l'IA, en tenant compte des connaissances des personnes et du contexte, et, dans les termes que le règlement emploie désormais, aucune obligation de garantir un niveau spécifique de maîtrise par un individu. La Commission doit publier des exemples pratiques et le Comité IA des objectifs communs. Ce que l'article demande, pourquoi il n'a pas d'amende propre à l'article 99, comment les paragraphes compétence et sensibilisation de l'ISO 42001 produisent l'enregistrement, et un programme d'une page.
12 septembre 2026
La notice d'information RGPD pour une entreprise de logiciels : les douze informations de l'article 13, les treize de l'article 14, le moment où chacune est fournie, et une page qui la rédige
Une notice d'information n'est pas un genre ; c'est une liste. L'article 13 nomme douze informations qu'un responsable fournit au moment où les données à caractère personnel sont obtenues auprès de la personne, six dans tous les cas et six complémentaires pour un traitement équitable et transparent, et l'article 14 en nomme treize pour les données obtenues ailleurs, fournies dans un délai raisonnable et au plus tard dans un mois, avec quatre exceptions. Pour une entreprise de logiciels, sept d'entre elles sont déjà des colonnes de son registre des traitements. Chaque information telle que le Journal officiel la rédige, le moment où elle est fournie, les deux cas où elle n'est pas due, et une page gratuite qui rédige la notice à partir des réponses en six langues.
12 septembre 2026
La politique qualité ISO 9001 : les quatre choses que le paragraphe 5.2 exige, les trois choses qui doivent lui arriver, et un exemple d'une page
Le paragraphe 5.2 de l'ISO 9001:2015 est court et précis. La direction établit une politique qualité adaptée à la finalité et au contexte de l'organisme et qui soutient sa stratégie, fournit un cadre aux objectifs qualité, et s'engage à satisfaire les exigences applicables et à l'amélioration continue (5.2.1). La politique est ensuite tenue à jour comme information documentée, communiquée, comprise et appliquée dans l'organisme, et disponible pour les parties intéressées (5.2.2). Ce que chacune des sept exigences signifie pour une page de texte, les constats que relèvent les auditeurs, comment la même politique sert l'ISO 27001, et un exemple d'une page en nos propres mots.
12 septembre 2026
La revue de direction ISO 9001 : les 13 éléments d'entrée et 3 éléments de sortie du paragraphe 9.3 en ordre du jour, d'où vient chaque élément, et ce que le compte rendu doit montrer
Le paragraphe 9.3 de l'ISO 9001:2015 est la seule réunion dont la norme écrit l'ordre du jour. La direction revoit le système de management de la qualité à intervalles planifiés pour sa pertinence, son adéquation, son efficacité et son alignement avec la stratégie (9.3.1) ; considère treize éléments d'entrée, de l'état des actions de la fois précédente aux performances des prestataires externes (9.3.2) ; et décide de l'amélioration, des changements du système et des ressources (9.3.3), les résultats étant conservés comme information documentée. L'ordre du jour, l'enregistrement derrière chaque élément, ce que le compte rendu doit montrer, et comment la même réunion sert l'ISO 27001 et, pour les entités NIS2, la revue annuelle de la politique qu'exige le règlement d'exécution.
12 septembre 2026
Le contrat de sous-traitance RGPD pour une entreprise SaaS : les huit clauses de l'article 28, paragraphe 3, que tout avenant client porte, l'obligation que la plupart oublient, et ce qui se place à côté sous DORA
Une entreprise SaaS signe le même contrat avec chaque client pour lequel elle traite des données, et l'article 28, paragraphe 3, en fixe le contenu : l'objet et la durée, les huit engagements des instructions documentées aux audits, et l'obligation du sous-traitant de signaler une instruction qui enfreint le règlement. Ce que chaque clause signifie pour un éditeur de logiciels, la règle des sous-traitants ultérieurs de l'article 28, paragraphes 2 et 4, les clauses contractuelles types de la Commission de 2021, la responsabilité de l'article 82 et le plafond d'amende de l'article 83, et la clause DORA de l'article 30 qu'un client bancaire envoie à côté de chaque clause. Avec la liste de contrôle gratuite qui lit les deux avenants comme un seul.
12 septembre 2026
Le délai de 72 heures du RGPD pour une entreprise de logiciels : quand la prise de connaissance le déclenche, ce que contient la notification, le délai propre du sous-traitant, et les délais NIS2, CRA et DORA à côté
L'article 33 donne au responsable du traitement 72 heures à compter de la prise de connaissance d'une violation de données pour la notifier à l'autorité de contrôle, et la plupart des entreprises se trompent sur le départ, sur le contenu ou sur le rôle. Quand la prise de connaissance commence selon les lignes directrices du CEPD et le considérant 87, les quatre contenus de l'article 33, paragraphe 3, les phases de l'article 33, paragraphe 4, la règle des motifs du retard, l'obligation du sous-traitant de notifier le responsable dans les meilleurs délais, la communication aux personnes concernées au titre de l'article 34 et ses trois exceptions, et les délais NIS2, CRA et DORA qu'une entreprise de logiciels peut faire courir à partir du même moment. Avec la page gratuite qui calcule le délai et rédige la notification.
12 septembre 2026
Le périmètre ISO 27001 : pourquoi un certificat qui dit siège social ne couvre pas votre SaaS, ce que la clause 4.3 demande, ce qu'un acheteur sous DORA vérifie, et trois périmètres qui passent
Le périmètre est la limite du certificat, et les acheteurs le lisent désormais au regard d'un règlement : un client financier ne peut se fier à votre certificat ISO 27001 plutôt que de vous auditer que si son périmètre couvre les systèmes dont il dépend. Ce que la clause 4.3 de l'ISO/IEC 27001:2022 exige, ce que l'ISO/IEC 17021-1 fait figurer sur le certificat, le cycle de surveillance qui décide s'il est à jour, l'échéance de l'édition 2013 qui est passée, un périmètre qui échoue et trois qui passent pour une entreprise de logiciels, et comment les interfaces avec votre fournisseur de nuage restent dans le périmètre alors que le fournisseur reste dehors.
12 septembre 2026
Le registre RGPD des activités de traitement pour une entreprise de logiciels : les sept champs de l'article 30, paragraphe 1, les quatre de l'article 30, paragraphe 2, pourquoi la dispense à 250 personnes ne s'applique jamais, et une page qui le rédige
L'article 30 est la seule obligation du RGPD à laquelle toutes les autres renvoient, et celle dont la plupart des entreprises de logiciels croient que la dispense à 250 personnes les épargne. Ce n'est pas le cas : l'article 30, paragraphe 5, lève la dispense pour tout traitement qui n'est pas occasionnel, et un produit en service traite chaque jour. Les sept champs du registre d'un responsable et les quatre de celui d'un sous-traitant, lus dans le Journal officiel, à quoi sert chacun, la mesure ISO 27701 qui en fait la preuve, et la page gratuite qui rédige le registre une activité à la fois.
12 septembre 2026
Le règlement sur l'IA après l'omnibus numérique : les dates qui ont changé le 27 juillet 2026, et quelles mesures ISO 42001 produisent les preuves pour les treize aspects de l'article 17 et les articles 9 à 15
Le règlement (UE) 2026/1744, signé le 8 juillet 2026, publié le 24 juillet, en vigueur le 27 juillet, a repoussé les dates du règlement sur l'IA pour les systèmes à haut risque au 2 décembre 2027 pour ceux de l'annexe III et au 2 août 2028 pour ceux de l'annexe I, a réécrit la maîtrise de l'IA en obligation de prendre des mesures, et a fait du plan de surveillance après commercialisation une partie de la documentation technique. La plupart des pages qui se classent donnent encore les anciennes dates. Les dates telles que modifiées, ce qui a changé d'autre pour un fournisseur, et notre correspondance des treize aspects du système de gestion de la qualité de l'article 17, des articles 9 à 15, 72 et 73, et des obligations des opérateurs des articles 4 et 26 avec les mesures de l'annexe A de l'ISO/IEC 42001, avec ce que le règlement exige et que la norme ne produit pas.
12 septembre 2026
Le règlement sur l'IA pour une entreprise de logiciels : quel rôle vous avez, ce qui s'applique à tous, ce qui ne s'applique qu'à un fournisseur à haut risque, les dispositions PME et les dates modifiées
Une entreprise de logiciels rencontre le règlement sur l'IA dans l'un de six rôles, et l'essentiel du règlement ne s'applique qu'à deux d'entre eux. Ce qui compte comme système d'IA, pourquoi livrer le modèle d'un fournisseur sous votre propre nom fait de vous le fournisseur, les trois devoirs que toute entreprise a depuis 2025 et 2026 (maîtrise de l'IA, les interdictions, la transparence), les deux voies vers le haut risque et ce que chaque rôle doit alors à partir du 2 décembre 2027, la ligne des modèles à usage général, les dispositions PME et petites entreprises à moyenne capitalisation que l'omnibus numérique a élargies, et un tableau de qui doit quoi à partir de quand. Lu dans les deux règlements sur CELLAR le 12 septembre 2026.
12 septembre 2026
Le représentant RGPD de l'article 27 pour une entreprise de logiciels hors UE : qui doit en désigner un, les trois conditions de l'exemption et où va le nom
Une entreprise de logiciels sans établissement dans l'Union dont le produit est utilisé par des personnes qui s'y trouvent relève du règlement par l'article 3, paragraphe 2, et doit désigner par écrit un représentant dans l'Union (article 27, paragraphe 1), établi dans un État membre où sont ses utilisateurs (27, paragraphe 3), mandaté pour être contacté par les autorités de contrôle et les personnes concernées (27, paragraphe 4), et sans effet protecteur contre une action visant l'entreprise elle-même (27, paragraphe 5). L'exemption de l'article 27, paragraphe 2, point a), a trois conditions qui doivent toutes tenir, et un produit en usage échoue à la première. Où va le nom du représentant : la politique de confidentialité (article 13, paragraphe 1, point a)), le registre des traitements (article 30, paragraphe 1, point a)) et le registre que le représentant tient lui-même. Le niveau d'amende est l'article 83, paragraphe 4. Une page gratuite le décide à partir de deux questions.
12 septembre 2026
Le RGPD pour une entreprise de logiciels : responsable de ses propres données, sous-traitant pour ses clients, et les cinq obligations qui dépendent de la taille et des données
Le règlement (UE) 2016/679 atteint toute entreprise de logiciels, la question est donc quelles obligations s'appliquent. Les deux rôles par traitement (article 4), le registre des activités de traitement dont la dispense à 250 personnes n'épargne jamais un produit en service (article 30), le délégué (article 37), l'analyse d'impact (article 35), le représentant pour une entreprise hors de l'Union (article 27), les fondements des transferts (chapitre V), les délais de 72 heures et d'un mois, et ce que l'ISO 27701 produit pour chacun. Lu dans le Journal officiel, avec la détermination gratuite qui l'écrit.
12 septembre 2026
Les dix mesures de l'article 21(2) de NIS2 en liste de contrôle : chaque point cité, les sections du règlement derrière, et les mesures ISO 27001 qui les produisent déjà
L'article 21(2) dresse dix mesures que toute entité essentielle et importante doit prendre, des politiques d'analyse des risques à l'authentification à plusieurs facteurs. Pour les fournisseurs de services en nuage, de services gérés et les autres fournisseurs numériques, le règlement d'exécution 2024/2690 détaille chacune en 13 sections écrites à partir d'ISO/IEC 27001 et 27002. Un seul tableau : les dix points tels que la directive les formule, les sections qui détaillent chacun, et les clauses ISO 27001 et mesures de l'annexe A qui produisent les preuves, avec les deux endroits qu'un SMSI n'atteint pas.
12 septembre 2026
Les neuf endroits où le cadre de risque TIC de votre client bancaire entre dans votre produit, RTS 2024/1774 : dates de fin de support, rapports de vulnérabilités et suivi des bibliothèques, réglages qu'il ne doit pas pouvoir contourner, code source testé avant la production, comptes nominatifs pour votre personnel, et vos incidents comme ses alarmes
Le règlement délégué (UE) 2024/1774, en vigueur depuis le 15 juillet 2024, précise le cadre de gestion du risque lié aux TIC que chaque entité financière applique sous DORA, et neuf de ses articles nomment le prestataire tiers de services TIC. Lu du côté du prestataire : le registre des actifs qui enregistre les dates de fin de votre support (article 4), la procédure de vulnérabilités qui vérifie que vous traitez et signalez les vulnérabilités et suit les bibliothèques tierces de votre produit (article 10), la procédure de sécurité des données et des systèmes qui répartit les rôles entre vous et le client et demande des mesures sur votre infrastructure (article 11), les connexions chiffrées sur les réseaux tiers (article 13), le code source des prestataires analysé et testé avant la production (article 16), un compte unique pour chaque membre de votre personnel ayant un accès (article 20), vos notifications d'incident comme l'une de ses sources de détection (article 23), des tests de continuité qui incluent votre service et votre insolvabilité (articles 25 et 26). Avec ce qu'un système ISO 27001 répond déjà.
12 septembre 2026
Les tests de pénétration fondés sur la menace sous DORA, du côté du prestataire : quand l'équipe rouge de votre client bancaire est autorisée dans vos systèmes de production, le test de 12 semaines du RTS 2025/1190, le test groupé que vous pouvez mener à la place, et ce que le contrat dit déjà
L'article 26 de DORA fait exécuter aux plus grandes entités financières un test de pénétration fondé sur la menace sur les systèmes de production au moins tous les 3 ans, couvrant les fonctions critiques ou importantes qu'elles ont externalisées, et l'article 30, paragraphe 3, point d), met la participation du prestataire dans le contrat. Le règlement délégué (UE) 2025/1190, en vigueur depuis le 8 juillet 2025, en fixe la mécanique : une équipe de contrôle qui peut inclure votre personnel, une équipe bleue qui ne doit pas savoir, une phase active d'équipe rouge d'au moins 12 semaines, une rediffusion et un exercice violet dans les 10 semaines suivant sa fin, un plan de remédiation sous 8 semaines. L'article 26, paragraphe 4, permet à un prestataire dont les autres clients seraient lésés de contracter directement un testeur externe et de mener un seul test groupé pour plusieurs entités financières. Ce que le prestataire signe, ce qu'il peut refuser, et ce qu'un système ISO 27001 contient déjà. Lu au Journal officiel.
12 septembre 2026
NIS2 pour les fournisseurs de services gérés et les MSSP : une entité de l'annexe I par définition, et le fournisseur sur lequel tombe la diligence de chaque client
L'article 6(39) fait de quiconque installe, gère, exploite ou entretient des TIC pour des clients, sur place ou à distance, un fournisseur de services gérés, et l'article 6(40) fait de ceux qui aident à la gestion des risques de cybersécurité des MSSP. Les deux sont des types de l'annexe I : importants à taille moyenne, essentiels au-dessus des plafonds, sous la loi de l'établissement principal, au registre de l'ENISA, directement sous le règlement d'exécution 2024/2690, avec les quatre seuils d'incident de son article 10. Et le considérant 86 dit à chaque client essentiel et important de faire preuve d'une diligence accrue en vous choisissant.
12 septembre 2026
NIS2 pour les places de marché en ligne, les moteurs de recherche et les réseaux sociaux : les fournisseurs numériques de l'annexe II, et pourquoi ils ne sont jamais essentiels par la taille
Trois définitions empruntées à trois autres actes décident si une plateforme est un fournisseur numérique sous NIS2 : une place de marché où des consommateurs concluent des contrats à distance, un moteur de recherche qui explore en principe tous les sites, une plateforme où des utilisateurs finaux se connectent et partagent. Dans le champ à taille moyenne, importants au titre de l'article 3(2) si grands soient-ils, sous la loi de l'établissement principal, au registre de l'ENISA, sous le règlement d'exécution 2024/2690 avec leurs propres seuils d'incident aux articles 11 à 13 : pas de règle des 30 minutes, une part des utilisateurs à la place.
12 septembre 2026
NIS2 pour un éditeur SaaS : vous êtes un fournisseur de services d'informatique en nuage, et voici ce qui en découle
Le considérant 33 de la directive nomme le logiciel en tant que service parmi les modèles de services en nuage, de sorte qu'un éditeur SaaS de taille moyenne ou plus est une entité de NIS2 en tant que fournisseur de services d'informatique en nuage : importante sous les plafonds des moyennes entreprises, essentielle au-dessus. Ce qui suit, dans l'ordre où cela arrive : l'État de votre établissement principal, le registre où vous deviez figurer au plus tard le 17 janvier 2025, les mesures du règlement d'exécution 2024/2690, les quatre seuils d'incident de son article 7 et les horloges de l'article 23, et la ligne entre tout cela et le CRA.
12 septembre 2026
Normes harmonisées pour le CRA : ce que demande la demande de normalisation M/606, pour quand, et ce dont un fabricant dispose aujourd'hui
L'article 27 donne une présomption de conformité aux produits qui suivent des normes harmonisées citées au Journal officiel. Le 3 février 2025, la Commission en a demandé 41 au CEN, au CENELEC et à l'ETSI, avec des délais du 30 août 2026 au 30 octobre 2027 ; les trois ont accepté le 3 avril 2025. Le 12 septembre 2026, l'index des normes harmonisées de la Commission n'a toujours aucune entrée pour le règlement, ce qui, pour un produit de classe I, signifie aucune voie d'auto-évaluation au titre de l'article 32(2). Ce qui a été demandé, les dates, et contre quoi construire d'ici là.
12 septembre 2026
Quand votre panne devient l'incident majeur de votre client bancaire : les six critères de DORA, le seuil de deux heures d'indisponibilité du RTS 2024/1772, les délais de quatre heures, 24 heures, 72 heures et un mois du RTS 2025/301, et les faits dont votre client aura besoin de votre part
Une entité financière doit déclarer un incident majeur lié aux TIC à son autorité dans les quatre heures suivant sa classification et au plus tard 24 heures après en avoir eu connaissance, rendre un rapport intermédiaire sous 72 heures et clore sous un mois. Qu'une panne chez son éditeur de logiciels soit majeure ou non se décide selon six critères et les seuils du règlement délégué (UE) 2024/1772 : plus de deux heures d'indisponibilité d'un service soutenant une fonction critique ou importante, plus de 24 heures de durée, plus de 10 pour cent des clients, deux États membres ou plus, des pertes de données, 100 000 euros. Ce que chaque rapport doit contenir selon le règlement délégué (UE) 2025/301, lesquels de ces faits seul le prestataire détient, et ce que la clause d'assistance en cas d'incident de l'article 30, paragraphe 2, point f), en fait. Lu au Journal officiel.
12 septembre 2026
Quelle autorité de contrôle RGPD est la vôtre : l'établissement principal, l'autorité chef de file de l'article 56, les cas locaux et les 30 autorités du Comité
Une entreprise de logiciels avec des clients dans plusieurs États membres a une seule autorité de contrôle pour son traitement transfrontalier : l'autorité de son établissement principal, l'autorité chef de file de l'article 56, paragraphe 1, son interlocuteur unique au titre de l'article 56, paragraphe 6. Où elle se trouve, ce que l'établissement principal signifie pour un responsable du traitement et pour un sous-traitant (article 4, point 16), quand une autre autorité garde un cas local (article 56, paragraphe 2), ce qu'une entreprise sans établissement dans l'Union obtient à la place (article 27, considérant 122), et à qui va la notification de violation sous 72 heures (article 33, paragraphe 1). Avec les 27 autorités et les trois de l'EEE telles que le Comité européen de la protection des données liste ses membres, lues le 12 septembre 2026.
12 septembre 2026
Transferts internationaux RGPD pour une entreprise de logiciels : les 17 décisions d'adéquation, les quatre modules des CCT, ce qu'un sous-traitant américain, britannique ou indien exige, et une page qui choisit le mécanisme
Chaque hébergeur, service de support, outil d'analyse et service de paie hors de l'EEE est un transfert au titre du chapitre V. La liste des décisions d'adéquation de la Commission, lue le 12 septembre 2026, compte 17 entrées : 16 pays et territoires, d'Andorre à l'Uruguay, et l'Organisation européenne des brevets, avec le Royaume-Uni renouvelé en décembre 2025, le Brésil ajouté en janvier 2026, et les États-Unis couverts seulement pour les entreprises certifiées au titre du Data Privacy Framework. Tout le reste exige les clauses contractuelles types de la décision (UE) 2021/914, dont les quatre modules suivent les rôles de l'exportateur et de l'importateur, avec l'évaluation du droit local de la clause 14 avant le premier transfert ; les dérogations de l'article 49 sont pour l'occasion unique, jamais pour un produit en usage. Lu au regard du catalogue, avec une page gratuite qui choisit le mécanisme et le rédige.
12 septembre 2026
La transposition de NIS2, État par État : ce que montre le registre de la Commission elle-même
Pas le tableau de suivi d'un cabinet : les mesures nationales que les États membres ont communiquées à la Commission comme transposant la directive (UE) 2022/2555, lues auprès de l'Office des publications le 12 septembre 2026. 25 des 27 États en ont communiqué au moins une, 303 mesures en tout ; l'Espagne et l'Irlande aucune ; la France 15 textes, tous antérieurs à la directive. L'acte que chaque État appelle sa loi NIS2, la date de son entrée en vigueur, et ce qu'un éditeur de logiciels fait de la réponse.
12 septembre 2026
Ce que contient le dossier technique du CRA : l'annexe VII, point par point
À partir du 11 décembre 2027, tout produit comportant des éléments numériques mis sur le marché de l'UE a besoin d'une documentation technique avant sa mise sur le marché, conservée dix ans ou pendant la période d'assistance, la plus longue des deux. L'annexe VII dit ce qu'elle contient en huit points. Les voici, ce que chacun demande réellement, les quatre documents que la partie II de l'annexe I présuppose, et combien de temps vous la gardez.
11 septembre 2026
Ce que le CRA demande aux importateurs et distributeurs, et quand il fait d'eux le fabricant
Si vous revendez des logiciels ou des appareils dans l'UE plutôt que de les construire, les articles 19 et 20 du règlement sur la cyberrésilience vous donnent une liste de vérification à dérouler avant la mise en vente, l'obligation de transmettre les vulnérabilités au fabricant, l'obligation d'informer les autorités des risques importants, et dix ans de conservation. L'article 21 fait de vous le fabricant dès que vous vendez sous votre propre marque ou modifiez substantiellement le produit. Les obligations, d'après le texte.
11 septembre 2026
Ce que le CRA vous demande pour vos dépendances : diligence raisonnable, signalement en amont et vulnérabilités exploitables connues, d'après les orientations de la Commission
Un produit logiciel est surtout fait du code des autres. Le CRA rend le fabricant responsable du produit dans son ensemble et lui donne trois devoirs envers les composants qu'il contient : la diligence raisonnable de l'article 13(5), le signalement des vulnérabilités en amont et le partage des correctifs de l'article 13(6), et la mise sur le marché sans vulnérabilités exploitables connues. Les orientations de la Commission du 27 juillet 2026, sections 3.4, 7.3 et 9.2, disent ce que chacun exige et ce qu'il n'exige pas : pas de signalements en double, pas d'obligation de faire accepter votre correctif, et une définition de « connue » qui inclut la base CVE et la presse.
11 septembre 2026
Ce que vous devez notifier au titre du CRA : les deux déclencheurs, tels que le règlement les définit
L'article 14 a deux déclencheurs et les deux sont définis dans le texte. Une vulnérabilité activement exploitée est une vulnérabilité pour laquelle il existe des preuves fiables qu'un acteur malveillant l'a exploitée dans un système sans l'autorisation du propriétaire (article 3, point 42). Un incident grave est un incident qui affecte, ou peut affecter, la capacité du produit à protéger des données ou fonctions sensibles, ou qui conduit, ou peut conduire, à du code malveillant dans le produit ou les systèmes d'un utilisateur (article 14, paragraphe 5). Ce qui est dedans, ce qui est dehors, et l'obligation d'informer les utilisateurs qui accompagne les deux.
11 septembre 2026
CRA annexe I : les 22 exigences essentielles, en liste de contrôle
L'annexe I du règlement sur la cyberrésilience est ce que votre produit doit respecter à partir du 11 décembre 2027 et ce que le dossier technique doit démontrer. La partie I compte 14 exigences sur le produit, dont 13 « le cas échéant » sur la base de votre évaluation des risques ; la partie II compte 8 exigences de gestion des vulnérabilités qui s'appliquent toujours. Les voici en un seul tableau, avec ce que chacune demande et si vous pouvez l'exclure.
11 septembre 2026
CRA ou NIS2 : lequel s'applique à une société de logiciels, et peut-on être sous les deux ?
Le règlement sur la cyberrésilience régit les produits mis sur le marché ; NIS2 régit les entités qui fournissent des services. Une société de logiciels peut relever de l'un, de l'autre, des deux ou d'aucun, et la réponse tient à deux questions : mettez-vous un produit sur le marché, et êtes-vous une entité de taille moyenne ou plus dans un secteur listé. Les dates, les horloges de notification, les amendes et le tableau de décision, tirés des deux textes.
11 septembre 2026
Comment déposer une notification CRA sur la plateforme unique de l'ENISA, d'après son propre manuel
La plateforme a ouvert le 11 septembre 2026 à l'adresse portal.cra-srp.enisa.europa.eu. Qui peut se connecter, quel coordinateur choisir, ce que chacune des trois soumissions demande, ce que le compteur de la plateforme calcule mal, et quand vous pouvez demander que la diffusion soit retardée. Lu dans les guides, la FAQ, le glossaire et les conditions d'utilisation de l'ENISA, pas dans un résumé.
11 septembre 2026
L'auto-évaluation au titre du CRA : ce que le module A exige vraiment, d'après l'annexe VIII et la FAQ de la Commission
La plupart des produits logiciels ne verront jamais un organisme notifié. Ils utilisent le module A, la procédure de contrôle interne de l'annexe VIII, et « auto-évaluation » est le mot que tout le monde emploie sans dire ce qu'il contient. L'annexe VIII, partie I, tient en cinq points ; la FAQ de la Commission ajoute la liste des activités, le fait qu'aucune méthodologie d'essai n'est imposée, l'endroit où un produit logiciel porte son marquage CE, les deux formes de la déclaration de conformité, et le calendrier des normes harmonisées qui décide quand l'auto-évaluation cesse de vouloir dire « directement contre l'annexe I ».
11 septembre 2026
L'évaluation des risques de cybersécurité du CRA : ce que l'article 13 exige vraiment, et le seul résultat qu'elle doit produire
L'article 13, paragraphes 2 à 4, du règlement sur la cyberrésilience fait de l'évaluation des risques le document dont dépend toute autre obligation du CRA. Elle doit analyser les risques d'après la finalité, l'utilisation prévisible et les conditions d'utilisation sur la durée d'utilisation attendue ; dire si et comment chaque exigence du point 2 de la partie I s'applique ; dire comment le point 1 de la partie I et la partie II sont appliqués ; être documentée, tenue à jour sur la période d'assistance et incluse dans le dossier technique, avec une justification claire pour chaque exigence écartée. Les quatre paragraphes, et une structure d'une page qui y satisfait.
11 septembre 2026
La machinerie CRA de l'UE elle-même, le jour où l'obligation a commencé : 0 organisme notifié, 0 norme harmonisée, 7 autorités d'application sur 27
Le règlement sur la cyberrésilience demande aux fabricants d'être prêts. Voici l'état de préparation des institutions dont il dépend les 11 et 12 septembre 2026, lu dans les registres de la Commission elle-même : aucun organisme d'évaluation de la conformité notifié au titre du CRA, aucune norme harmonisée publiée au Journal officiel, sept États membres avec une autorité de surveillance du marché enregistrée, treize avec une autorité notifiante, et la liste des CSIRT coordinateurs publiée la veille, deux États nommant un organisme autre que leur CSIRT national. Ce que cela signifie pour un fabricant ayant un produit de classe I, et ce qu'il faut consigner.
11 septembre 2026
La politique de divulgation coordonnée des vulnérabilités exigée par le CRA : trois dispositions, et une politique d'une page qui y répond
L'annexe I, partie II, point 5 du règlement sur la cyberrésilience exige de tout fabricant dans le champ qu'il mette en place et applique une politique de divulgation coordonnée des vulnérabilités. L'article 13, paragraphe 17, exige un point de contact unique pour les signalements, facile à trouver et non limité à des outils automatisés ; l'annexe II, point 2, exige le contact et l'emplacement de la politique dans les informations utilisateur ; l'annexe VII, point 2 b), met les deux dans le dossier technique. Ce que chaque disposition demande, ce qu'une politique doit dire, et ce qu'elle ne doit pas promettre.
11 septembre 2026
Le CRA exige-t-il une SBOM ? Oui, et voici exactement ce qu'il dit
L'annexe I, partie II, point 1 du règlement sur la cyberrésilience exige une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau. Elle va dans le dossier technique, n'est pas publiée, et une autorité de surveillance du marché peut la demander sur demande motivée. Les trois phrases qui tranchent, et ce qu'elles laissent ouvert.
11 septembre 2026
Le CRA s'applique-t-il aux logiciels libres ? Trois cas, et le régime allégé des gestionnaires
Le règlement sur la cyberrésilience n'atteint les logiciels libres et ouverts que lorsqu'ils sont fournis dans le cadre d'une activité commerciale. Un projet non monétisé est dehors. Une entreprise qui livre un produit construit sur des composants libres est fabricant de ce produit. Et les fondations et entreprises qui soutiennent des produits libres destinés à un usage commercial sont des « gestionnaires de logiciels libres » au titre de l'article 24 : une politique de cybersécurité, la coopération avec les autorités et une obligation de notification restreinte, sans marquage CE ni dossier technique. Les considérants et l'article, cités.
11 septembre 2026
Le règlement sur la cyberrésilience pour un petit fabricant de logiciels, en douze étapes
Tout ce qu'une entreprise de dix personnes qui livre un logiciel installé ou un appareil doit faire au titre du CRA, dans l'ordre où le faire : la détermination du champ d'application, le palier, le CSIRT et l'autorité d'application, la procédure de notification en vigueur depuis le 11 septembre 2026, puis le dossier technique, les 22 exigences, la SBOM, la période d'assistance, le marquage CE et la déclaration dus pour le 11 décembre 2027. Chaque étape avec son article et le texte qui l'explique.
11 septembre 2026
Le délai du rapport final du CRA ne part pas du moment où vous avez connaissance
La plupart des présentations de l'article 14 du règlement sur la cyberrésilience donnent trois délais depuis un seul point de départ : 24 heures, 72 heures, 14 jours. Les deux premiers partent de la connaissance. Le troisième non, et pour une vulnérabilité son point de départ est une date qui peut ne pas encore exister. Voici ce que dit le règlement, paragraphe par paragraphe.
11 septembre 2026
NIS2 ou CRA : quelle horloge d'incident court pour un éditeur de logiciels, et ce qui rend un incident « important »
Les deux textes vous donnent 24 heures, 72 heures et un mois, et les deux font partir l'horloge du moment où vous « avez connaissance ». Presque tout le reste diffère : ce qui la déclenche, qui la reçoit, sur quelle plateforme, et ce qui compte. L'article 23 de NIS2 et le règlement d'exécution 2024/2690 pour l'entreprise qui exploite un service en nuage ; l'article 14 du CRA pour l'entreprise qui livre un produit ; les deux pour l'entreprise qui fait les deux. Les seuils, critère par critère, et une seule procédure qui satisfait aux deux.
11 septembre 2026
Par défaut, important ou critique : les 26 descriptions techniques du règlement d'exécution 2025/2392, et le test de la fonctionnalité de base
Les annexes III et IV du CRA nomment 26 catégories de produits en une ligne chacune. Le règlement d'exécution (UE) 2025/2392 de la Commission, en vigueur depuis le 21 décembre 2025, décrit chacune techniquement, et les orientations de la Commission du 27 juillet 2026 disent comment classer par rapport à elles : selon la fonctionnalité de base du produit, pas selon ce qu'il fait aussi ni ce qu'il intègre. Les 26 descriptions textuellement, les six règles des orientations avec leurs exemples (un SOAR n'est pas un SIEM, un visualiseur de journaux n'est pas un SIEM, un routeur avec pare-feu est un routeur), et ce que la classification change.
11 septembre 2026
Quand démarre l'horloge de 24 heures du CRA ? La « prise de connaissance », d'après les orientations de la Commission
Les 24 et 72 heures courent à partir du moment où le fabricant « a connaissance », et le règlement ne dit jamais ce que cela signifie. Les orientations de la Commission du 27 juillet 2026 le disent, aux paragraphes 211 à 218 : un degré raisonnable de certitude, après une évaluation initiale, repris mot pour mot du règlement d'exécution NIS2 et des lignes directrices sur les violations de données du RGPD. Ce que cela fait d'un courriel de client, d'une alerte de scanner, d'une CVE listée dans un composant, d'un zero-day de bug bounty et d'une vulnérabilité que vous connaissiez avant le 11 septembre.
11 septembre 2026
Quand un logiciel est-il « mis sur le marché » au sens du CRA, et lequel de vos builds est un produit ? La règle des orientations pour les logiciels autonomes
Tout, dans le CRA, tient à une date et à un nom : la date à laquelle un produit est mis sur le marché, et la question de savoir si ce que vous livrez est un produit. Pour les logiciels autonomes, les orientations de la Commission du 27 juillet 2026 répondent aux deux aux paragraphes 13 à 21 : une version est mise sur le marché une fois, lors de sa première offre, et chaque téléchargement ultérieur compte à partir de ce jour ; les builds par système d'exploitation et les bundles de fonctionnalités sont des produits distincts ; une application web utilisée dans un navigateur n'est pas un produit, une extension de navigateur ou un client installé l'est. Ce que cela signifie pour le 11 décembre 2027, pour les bêtas et pour les anciennes versions que vous laissez en ligne.
11 septembre 2026
À quel CSIRT notifier au titre de l'article 14 du CRA ? Les 27 coordinateurs, tels que l'ENISA les répertorie
Tous les guides sur l'obligation de notification du Cyber Resilience Act disent « notifiez votre CSIRT national » et s'arrêtent là. Depuis le 10 septembre 2026, l'ENISA publie le CSIRT désigné comme coordinateur pour chacun des 27 États membres. Voici cette liste, la règle qui détermine l'État, et les deux États où le coordinateur n'est pas le CSIRT national.
11 septembre 2026
Quelle est la durée de la période d'assistance du CRA ? Au moins cinq ans, et trois autres horloges qui en dépendent
L'article 13, paragraphe 8, du règlement sur la cyberrésilience exige une période d'assistance d'au moins cinq ans, ou la durée d'utilisation attendue si elle est plus courte, pendant laquelle les vulnérabilités sont traitées. Sa date de fin doit être affichée à l'achat, au moins le mois et l'année. Les mises à jour de sécurité doivent rester disponibles dix ans ou la période d'assistance. Et le dossier technique, la déclaration et les informations utilisateur sont conservés aussi longtemps. Les quatre horloges, d'après le texte.
11 septembre 2026
Quelle mise à jour fait entrer votre logiciel existant dans le CRA ? Les modifications substantielles, d'après les orientations de la Commission
Un logiciel mis sur le marché avant le 11 décembre 2027 reste hors des obligations de conception et de conformité du CRA tant qu'il n'est pas substantiellement modifié. Les orientations de la Commission du 27 juillet 2026 disent ce que cela signifie pour une mise à jour logicielle aux paragraphes 103 à 113 et 122 à 124, avec onze exemples traités : un risque absent de votre évaluation des risques, pas la taille du diff. Les mises à jour de sécurité sont en général hors champ ; une case « se souvenir de moi » peut être dedans. Ce qu'il faut écrire dans chaque version, et ce que la première modification substantielle déclenche ou non.
11 septembre 2026
Quelles parties de votre backend sont dans le CRA ? Le traitement de données à distance, d'après les orientations de la Commission
Un produit comportant des éléments numériques inclut ses solutions de traitement de données à distance, et le règlement les définit en une phrase. Les orientations de la Commission du 27 juillet 2026 font de cette phrase deux tests cumulatifs, une règle de délimitation, une liste de ce qui n'est jamais inclus (CI/CD, RH, CRM, télémétrie, sites web), les cas SaaS, PaaS et IaaS, et un exemple de banque mobile traité de bout en bout. Pour un éditeur de logiciels avec une application et un cloud, c'est la ligne.
11 septembre 2026
Qui applique le règlement sur la cyberrésilience dans votre État membre ? 7 sur 27 l'ont dit
Le CRA est appliqué au niveau national, par une autorité de surveillance du marché que chaque État membre désigne et enregistre auprès de la Commission. Le 11 septembre 2026, jour où l'obligation de notification s'est appliquée, sept États en avaient enregistré une. Voici le registre, État par État, y compris les vingt qui ne l'ont pas fait, et ce que cela signifie pour un petit fabricant qui se demande qui viendra frapper à sa porte.
11 septembre 2026
Un logiciel doit-il porter le marquage CE au titre du CRA ? Oui, et l'article 30 dit où il va
À partir du 11 décembre 2027, un marquage CE est exigé sur tout produit comportant des éléments numériques mis sur le marché de l'UE, logiciel compris. Pour un logiciel, le marquage va sur la déclaration UE de conformité ou sur le site web accompagnant le produit, avant la mise sur le marché. Ce que le marquage affirme, qui peut l'apposer, quand le numéro d'un organisme notifié s'y ajoute, et ce que doit contenir la déclaration qui le sous-tend.
11 septembre 2026
Votre produit entre-t-il dans le champ du règlement sur la cyberrésilience ? Où se situe le SaaS
La question la plus posée sur le CRA n'est pas comment notifier, c'est si le règlement s'applique à vous. Le pur logiciel en tant que service est hors champ et relève de NIS2 ; le logiciel installé et téléchargeable est dedans ; le traitement à distance sans lequel un produit ne fonctionne pas y revient. La détermination vous appartient et doit être consignée. Voici le texte qui la décide.
11 septembre 2026
Votre produit est-il important ou critique au sens du règlement sur la cyberrésilience ? Les annexes III et IV en entier
Une fois qu'un produit entre dans le champ du CRA, il est par défaut, important (classe I ou II) ou critique, et le palier décide si vous pouvez vous auto-évaluer ou s'il vous faut un organisme notifié. Voici les 19, 4 et 3 catégories mot pour mot depuis le Journal officiel, ce que chaque palier change au titre de l'article 32, et la seule chose que le palier ne change pas.
11 septembre 2026
Votre projet open source est-il « commercial » au sens du CRA ? Les sept tests de la Commission, avec ses exemples
Le CRA n'atteint les logiciels libres et open source que lorsqu'ils sont fournis dans le cadre d'une activité commerciale, et le règlement laisse « commercial » à deux considérants. Les orientations de la Commission du 27 juillet 2026, section 3, en font sept tests : un prix, une édition payante ou de l'open core, la monétisation d'autres services ou de données personnelles, les services de support, les dons, le sponsoring et le statut à but non lucratif, avec 22 exemples. Où atterrissent un mainteneur, une entreprise open core et une fondation, et ce qu'une pull request fait de vous.
11 septembre 2026
Sanctions du Cyber Resilience Act : à quoi un petit fabricant est réellement exposé
Le CRA fixe trois niveaux d'amende, jusqu'à 15 millions d'EUR ou 2,5 % du chiffre d'affaires mondial. Voici quelles obligations relèvent de quel niveau, qui fait respecter le texte, et les deux endroits où le règlement nomme les petits fabricants.
8 septembre 2026
Quels pays de l'UE citent l'ISO 27001 dans leurs marchés publics : 1 548 avis allemands, 829 polonais, et la Grèce a la part la plus élevée
Sur 365 jours, l'ISO 27001 apparaît dans 3 415 avis TED. L'Allemagne et la Pologne en représentent 70 %, la Grèce la cite dans 2 % de tout ce qu'elle achète, et la France, l'Espagne et l'Italie la citent à peine. Voici le tableau, la requête et ce que les chiffres veulent dire.
3 septembre 2026
Comment répondre à un questionnaire de sécurité depuis votre SMSI ISO 27001 : 30 thèmes de questions rapportés aux mesures de l'annexe A qui y répondent
Presque tous les questionnaires de sécurité qu'une entreprise européenne reçoit portent sur les mêmes 30 thèmes. Voici la correspondance de chaque thème vers les mesures de l'annexe A de l'ISO 27001 dont il est vraiment question, et les quatre enregistrements que chaque réponse devrait porter.
3 septembre 2026
Certification ISO 27001 la moins chère : comparer les devis sans acheter un certificat sans valeur
Les devis des organismes de certification varient, mais les jours d'auditeur derrière eux sont fixés par l'annexe B de l'ISO/IEC 27006. Voici comment lire un devis, et la seule vérification qui compte plus que le prix.
20 août 2026
Certification ISO 42001 : ce que c'est, et si c'est trop tôt
L'ISO/IEC 42001 est la norme de système de management de l'IA. Voici ce qu'elle demande, comment elle s'articule avec une ISO 27001 existante, et une lecture honnête de la demande actuelle.
20 août 2026
Comment obtenir la certification ISO 27001 pour une entreprise, dans l'ordre où cela se passe vraiment
Le chemin de rien jusqu'au certificat, ce qui se passe à l'étape 1 et à l'étape 2, et les enregistrements qu'un auditeur demande à chaque point.
20 août 2026
Coût de la certification ISO 27001 pour une entreprise, selon l'effectif
Les jours d'auditeur viennent du tableau de l'annexe B de l'ISO/IEC 27006, si bien que le coût de la certification suit l'effectif plus que le secteur. Voici l'arithmétique, et les lignes que l'on oublie.
20 août 2026
Coût de mise en œuvre de l'ISO 27001 : le chiffre sur trois ans, pas la première facture
La certification suit un cycle de trois ans avec des audits de surveillance chaque année. Ne budgéter que le premier audit est la façon la plus courante de se laisser surprendre par le total.
20 août 2026
ISO 27001 vs NIS2 : ce que le certificat couvre et ce qu'il ne couvre pas
NIS2 est une loi et l'ISO 27001 une norme certifiable, elles ne sont donc pas des alternatives. Voici où un SMSI existant satisfait aux exigences de la directive, et les deux endroits où il ne le fait pas.
20 août 2026
Le moyen le moins cher d'obtenir l'ISO 27001, et la partie que vous ne pouvez pas rendre moins chère
L'essentiel d'un budget ISO 27001, ce sont des jours d'auditeur, et ceux-ci sont fixés par un tableau publié plutôt que par négociation. Voici ce qui fait vraiment bouger le chiffre, et ce qui ne le fait pas.
20 août 2026
Liste de contrôle de conformité ISO 27001, chapitre par chapitre
Une liste de contrôle qui suit la structure de la norme elle-même : les chapitres 4 à 10 et ce que chacun vous demande d'être capable de montrer, plus ce qu'ajoute l'annexe A.
20 août 2026
Meilleur logiciel de conformité ISO 27001 : ce qu'il faut demander avant de comparer les fonctionnalités
Le nombre d'intégrations est facile à comparer et décide rarement d'un audit. Voici les questions qui le font, dont celle à laquelle la plupart des éditeurs ne répondront pas par écrit.
20 août 2026
Mettre en œuvre l'ISO 27001 sans consultants : ce que vous prenez en charge, et ce qu'ils faisaient pour l'argent
Il est tout à fait possible de se certifier sans consultant. Il vaut la peine de savoir d'abord ce que vous absorbez, et quelles parties gagnent vraiment à avoir quelqu'un qui s'est assis de l'autre côté de la table.
20 août 2026
Combien de jours d'auditeur prend une certification ISO 27001, selon l'effectif
Les organismes de certification ne publient pas leurs prix, mais les jours d'audit sont fixés par l'annexe B de l'ISO/IEC 27006. Voici l'arithmétique qui transforme votre effectif en un chiffre avant que quiconque vous fasse un devis.
11 août 2026
ISO 27001 vs SOC 2 en Europe : ce que les acheteurs demandent vraiment
Pour vendre en Europe, visez l'ISO 27001 : les appels d'offres publics de l'UE l'ont citée 3 408 fois en un an, contre 104 pour SOC 2. Pour vendre à des clients américains, c'est l'inverse. Les chiffres, la requête TED publique pour les recalculer, et quand il vous faut les deux.
11 août 2026