La sécurité sans jargon.

On ne prévoit pas la porte d’entrée après avoir emménagé. De même, un logiciel doit intégrer les besoins de protection, les données sensibles, les accès et les erreurs possibles dans ses exigences et son architecture.

Nous clarifions les besoins de protection et les risques avant la réalisation, documentons les décisions et réexaminons les mesures pendant le développement.

Un nouveau logement est livré avec la porte d’entrée fermée. Personne ne devrait devoir chercher de nombreux réglages avant qu’un système soit correctement protégé.

Les nouveaux comptes ne reçoivent que les droits nécessaires, les fonctions risquées restent désactivées et la protection ne dépend pas de connaissances supplémentaires.

Avant une randonnée, on vérifie la météo, l’itinéraire et les issues possibles. Pour un logiciel, on examine aussi ce qui doit être protégé, qui pourrait attaquer et quelles seraient les conséquences d’une panne.

Les risques réalistes deviennent des exigences, des tests et des priorités concrètes, plutôt qu’une liste confuse de dangers théoriques.

Pour retirer un colis, personne n’a besoin de raconter toute sa vie. Les systèmes doivent demander uniquement les données nécessaires, les protéger et utiliser des réglages respectueux de la vie privée.

La finalité, la durée de conservation, les droits et la suppression sont définis dès la planification et non ajoutés après coup.

Un client d’hôtel reçoit la clé de sa chambre, pas de toutes les chambres, de la cuisine et du bureau. Les utilisateurs et applications ne doivent accéder qu’à ce qui leur est nécessaire.

Les rôles restent limités et compréhensibles. Les droits supplémentaires sont accordés consciemment, vérifiés régulièrement puis retirés.

Une pièce importante peut nécessiter une clé et un code personnel. Si un facteur est volé, l’attaquant ne possède toujours pas la seconde preuve.

Les comptes sensibles et les accès administratifs sont protégés par un second facteur indépendant.

Un bracelet de festival autorise l’entrée, mais pas automatiquement l’accès aux coulisses. Les zones sensibles nécessitent une nouvelle vérification de la personne et du contexte.

L’identité, l’appareil, le rôle et le contexte sont évalués ensemble ; un utilisateur connecté ne bénéficie pas automatiquement d’une confiance illimitée.

Comme une lettre fermée, le chiffrement protège le contenu. Une personne observant le transport ou trouvant un support ne doit pas pouvoir le lire sans la clé.

Selon le besoin de protection, les données sont chiffrées pendant le transport et le stockage, avec des clés gérées séparément et de manière contrôlée.

Même un bon vélo doit être contrôlé régulièrement. Les vulnérabilités logicielles sont surveillées, classées selon le risque et traitées par des mises à jour ou d’autres mesures.

Les dépendances, mises à jour et vulnérabilités signalées sont suivies, avec une procédure claire pour les points critiques.

Comme dans un carnet de bord, le système ne montre pas seulement l’état actuel. Il indique aussi qui a ajouté, confirmé ou modifié une information et à quel moment.

Les opérations importantes disposent d’un historique immuable ou spécialement protégé. L’accès au journal est limité et sa conservation adaptée à l’usage.

Au lieu de fichiers nommés « final_nouveau_2 », une version actuelle est clairement définie. Toute modification crée une nouvelle version sans écraser silencieusement l’ancienne.

Les versions indiquent la date, l’origine et la responsabilité. Les personnes autorisées peuvent comparer les différences et restaurer un état antérieur.

Une copie dans le même dossier n’est pas encore une sauvegarde fiable. Une bonne sauvegarde est protégée, régulière et réellement restaurable.

La fréquence, le stockage séparé, la protection des accès et les tests de restauration sont adaptés à l’importance des données.

Comme pour une alarme incendie, les responsabilités, les premières étapes et les voies de communication doivent être connues à l’avance afin de limiter, analyser et traiter l’incident.

La journalisation, les alertes, la restauration et les procédures de notification sont préparées selon le risque et vérifiées régulièrement.

Un vélo n’est fiable que si ses pièces le sont. Un logiciel utilise des bibliothèques, services et infrastructures tiers : leur origine et leur entretien comptent également.

Les dépendances importantes sont documentées, mises à jour et vérifiées ; les composants inutiles ou peu clairs sont évités.

Le RGPD concerne les informations relatives aux personnes. En bref : il faut une finalité claire, une base juridique adaptée, le moins de données possible et une protection appropriée.

Nous prenons en compte les flux, la finalité, les droits, la conservation et la suppression dès la planification. Le responsable du traitement doit vérifier la licéité de chaque usage concret.

NIS2 impose aux organisations concernées de gérer systématiquement les risques de cybersécurité et de notifier les incidents importants. Elle ne s’applique pas automatiquement à chaque petite entreprise ou projet logiciel.

Lorsque NIS2 peut être pertinente, nous prévoyons l’analyse des risques, la protection des accès, la chaîne d’approvisionnement, les vulnérabilités, la restauration et les incidents. L’applicabilité est vérifiée pour chaque organisation.

Le CRA couvre de nombreux produits comportant des éléments numériques. Les fabricants doivent intégrer la sécurité dans la planification, le développement et la maintenance, ainsi que les notifications requises.

Pour les produits concernés, les réglages sûrs, les composants documentés, les mises à jour et la gestion prévue des vulnérabilités font partie du concept.

Une IA qui classe des notes personnelles n’est pas comparable à une IA influençant l’éducation, l’emploi ou les soins. Le règlement distingue donc les systèmes selon leur risque et leur finalité.

Les fonctions d’IA sont visibles, leurs limites sont documentées et un contrôle humain est prévu lorsque les décisions ont des conséquences. La classification dépend de l’usage concret.

Comme une pièce d’identité numérique, un portefeuille européen doit fournir des justificatifs sélectionnés de manière sûre et contrôlée. Chacun doit voir qui demande quoi et dans quel but.

Pour les fonctions d’identité et de confiance, nous considérons la divulgation sélective, un consentement compréhensible et des interfaces interopérables, sans revendiquer de conformité officielle.

Le DSA ne concerne pas chaque site web. Il réglemente surtout les services qui hébergent ou diffusent des contenus ou offres de tiers, avec des obligations de transparence et de traitement des contenus illicites.

Pour les fonctions de plateforme, nous clarifions tôt le rôle réel du service et les procédures de signalement, transparence ou modération à soutenir techniquement.