Autodéclaration CRA

Documentez votre contact sécurité et votre durée de support, en deux minutes. Vos indications produisent trois textes prêts à copier : un security.txt, une section readme pour wordpress.org et des informations de sécurité publiques pour votre site. Tout se passe dans votre navigateur, rien n’est transmis et rien n’est enregistré.

Cet outil crée des modèles de texte à partir de vos propres indications. C’est une aide à l’orientation, pas une évaluation de la conformité. Il ne vérifie pas si le règlement sur la cyberrésilience s’applique à votre produit, et il n’évalue pas si vos indications ou votre produit répondent aux exigences légales. Les textes générés ne constituent pas un conseil juridique et ne remplacent pas l’examen par un avocat ou une avocate, en particulier sur la question de savoir si et dans quelle mesure le règlement sur la cyberrésilience s’applique à vous et quelle durée de support convient à votre produit. Vous répondez de l’exactitude du contenu des textes que vous publiez. Toutes les indications sans garantie, état août 2026.
Le nom du produit tel qu’il figure dans l’annuaire ou la boutique.
Laissez vide si les indications valent pour tout le produit.
Nom de l’entreprise ou de la personne, comme dans les mentions légales.
Utilisée pour la ligne canonical du security.txt.
Une boîte dédiée comme security@ vaut mieux que le forum de support. L’adresse est seulement insérée dans les textes générés, elle n’est envoyée nulle part.
Par exemple une page sur la divulgation coordonnée des vulnérabilités. Sans saisie, la ligne Policy disparaît.
Sans saisie, la ligne Encryption disparaît.
L’art. 13, paragraphe 8 du CRA parle d’au moins cinq ans, ou de la durée de vie attendue du produit si elle est plus courte.
À noter : cette date est un engagement public, pas une déclaration d’intention. Qui ne livre pas de mises à jour de sécurité jusque-là s’y est engagé tout de même. En cas de doute, fixez une date plus courte et prolongez plus tard.
Langues de signalement préférées
Le security.txt et la section readme sont toujours en anglais, c’est la convention.

1. security.txt

À déposer sous /.well-known/security.txt

					

						
						
					

					
Modèle issu de vos indications, pas un conseil juridique. Vérifiez le contenu avant publication, et consultez un avocat en cas de doute.

				


				

					
2. Section readme pour wordpress.org

					
Dans le readme.txt de l’extension, en section distincte

					

					

						
						
					

					
Modèle issu de vos indications, pas un conseil juridique. Vérifiez le contenu avant publication, et consultez un avocat en cas de doute.

				


				

					
3. Informations de sécurité publiques

					
Pour une page comme /securite ou l’espace produit

					

					

						
						
					

					
Modèle issu de vos indications, pas un conseil juridique. Vérifiez le contenu avant publication, et consultez un avocat en cas de doute.

				

			


			

				
Échéances du règlement sur la cyberrésilience (règlement (UE) 2024/2847), état août 2026 : les obligations de signalement prévues à l’art. 14 s’appliquent à partir du 11/09/2026, l’ensemble des obligations du fabricant à partir du 11/12/2027. Pour une nomenclature de vos dépendances (SBOM), cyclonedx/cyclonedx-php-composer est la voie habituelle, cet outil ne génère pas de SBOM.

				
Le security.txt terminé a ensuite sa place sur le serveur, sous /.well-known/. Pour forcer HTTPS et poser des en-têtes de sécurité sur le même serveur, il y a ici le générateur .htaccess, lui aussi gratuit et sans compte. Pour voir à quoi ressemble une page de sécurité terminée, regardez notre propre page de sécurité, qui est en même temps notre politique de divulgation coordonnée des vulnérabilités. Les échéances vérifiées et quatre premières étapes, de la liste des composants à la voie de signalement, figurent sur notre page Cyber Resilience Act : échéances et que faire maintenant (en allemand).

				
← Tous les outils gratuits