Normes et standards
Les référentiels sur lesquels nos pratiques s'appuient
Le développement logiciel est un métier vaste, où presque chaque décision technique peut se discuter à l'infini. Nous préférons nous appuyer sur des référentiels publics plutôt que sur des préférences maison : nos délais et nos contrôles deviennent vérifiables, et nos échanges avec vous s'appuient sur un vocabulaire commun.
Cette section liste ce sur quoi nous nous appuyons et ce que nous en retenons concrètement.
Notre position
Ne pas réinventer la roue, sans se perdre dans l'administratif
Sur la plupart des sujets techniques que nous traitons, quelqu'un a déjà fait le travail de cadrage, souvent mieux que nous ne le ferions, et l'a publié.
Comment noter la gravité d'une faille, comment nommer les types de maintenance, quelles familles de vulnérabilités reviennent le plus : tout cela existe, gratuitement, et se cite. S'appuyer dessus a un avantage direct pour vous, nos décisions cessent d'être des préférences maison. Quand nous disons qu'une faille exploitée activement se traite en jours et non en semaines, ce n'est pas notre avis, c'est une pratique documentée à laquelle nous pouvons renvoyer.
L'inverse existe aussi, et il est plus fréquent : des démarches qui produisent des classeurs, des matrices et des attestations sans rien changer au logiciel livré. Nous ne voulons pas tomber dans cet excès ! Un référentiel nous intéresse quand il améliore nettement une pratique, un délai ou un contrôle. S'il ne modifie rien, il n'a pas sa place ici.
C'est pourquoi chaque référentiel retenu a sa page, qui dit ce qu'il change sur un projet réel et où s'arrête son usage chez nous. La liste ci-dessous s'étoffe à mesure que ces pages s'écrivent, jamais avant.
Ce que nous appliquons
Les référentiels qui orientent notre travail
Chacun a sa page : ce que le référentiel couvre, ce qu'il change sur un projet réel, et le lien vers la publication officielle.
Notre registre en suit d'autres, encore à l'état de fiche interne. Nous ne publions ici que ceux dont la page est écrite : annoncer les autres promettrait une couverture que rien ne soutient encore.
OWASP Top 10:2025
Référentiel · OWASP Foundation
Les dix familles de failles les plus fréquentes sur les applications web, établies à partir de données de vulnérabilités réelles et renumérotées à chaque édition.
En savoir plus
Common Vulnerabilities and Exposures
Référentiel · CVE Program (MITRE, financement CISA)
L'attribution d'un identifiant public et unique à chaque vulnérabilité constatée dans un produit, par un réseau d'autorités de nommage réparties dans le monde.
En savoir plus
Common Weakness Enumeration 4.20
Référentiel · MITRE
La taxonomie des types de faiblesse logicielle : 944 entrées hiérarchisées, du défaut de conception à l'erreur d'implémentation, indépendamment du produit où elles apparaissent.
En savoir plus
Semantic Versioning 2.0.0
Référentiel · Tom Preston-Werner
La convention de numérotation MAJEUR.MINEUR.CORRECTIF qui structure la gestion des mises à jour de nos dépendances.
En savoir plus
De quoi parle-t-on
Quatre types de référence, quatre portées
Ces mots sont employés l'un pour l'autre, et la confusion a des conséquences : présenter un référentiel comme une norme, ou une norme comme une obligation légale, fausse la discussion budgétaire. Chaque entrée de cette page porte donc sa famille.
- Une norme
- Publiée par un organisme de normalisation : ISO, IEC, IEEE. Elle est payante, révisée à intervalles longs, et sert de référence commune entre des organisations qui ne se connaissent pas. Exemple : ISO/IEC 27001 sur la sécurité de l'information.
- Un référentiel
- Publié par une fondation ou une communauté : OWASP, CIS, FIRST. Gratuit, révisé souvent, il fait autorité par son adoption et non par un statut officiel. Ce n'est pas une norme, et le présenter comme telle est l'erreur la plus courante. Exemple : l'OWASP Top 10.
- Une réglementation
- Un texte de droit, européen ou national, avec des échéances opposables et des sanctions. Contrairement aux deux précédents, on ne choisit pas de s'y conformer. Exemple : la directive NIS 2 et sa cascade d'exigences vers les fournisseurs.
- Une documentation officielle
- Ce que l'éditeur d'un outil publie sur son propre produit. Ni norme ni référentiel, mais la source qui fait foi sur le comportement réel de la brique, et la seule qui suive le rythme des versions. Exemple : la documentation de Symfony, de PHP ou de Vue.js.
La quatrième est celle qu'on saute le plus souvent, alors que c'est la première à connaître. Avant d'aller chercher un référentiel transverse, la documentation de l'outil qu'on utilise a le plus souvent déjà répondu : le composant d'authentification de Symfony, l'échappement par défaut de Twig, la politique de publication des versions de PHP. Elle est écrite par ceux qui ont codé la brique, elle est à jour à la version près, et elle n'a rien à vendre. Nous la lisons en premier : les référentiels ci-dessus viennent ensuite, quand la question dépasse un outil.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.