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.
Sur la partie technique, nous avons déjà ce réflexe : nous construisons sur Symfony et Vue.js plutôt que sur un framework maison, personne n'imaginerait plus faire autrement. Nous appliquons simplement la même logique à nos méthodes de travail.
Notre position
Ne pas réinventer la roue, sans se perdre dans l'administratif
Chaque référentiel retenu à été validé car il apporte une plus value claire à nos pratiques.
Ne pas réinventer la roue
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. Sur la plupart des sujets, quelqu'un a déjà fait le travail de cadrage, souvent mieux que nous ne le ferions.
Un meilleur service pour vous
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.
Sans se perdre dans l'administratif
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é. 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.
Ce que nous appliquons
Les référentiels qui structure notre travail
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é.
Nous avons la chance de pouvoir profiter de l'expertise d'un communauté mondiale sur plusieurs sujets alors pourquoi s'en passer ?
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.
Common Vulnerabilities and Exposures
Référentiel · CVE Program (MITRE, financement CISA)
La liste des vulnérabilités constatées dans un produit, par un réseau mondial d'autorités.
Common Weakness Enumeration 4.20
Référentiel · MITRE
Le catalogue des types de faiblesse logicielle : du défaut de conception à l'erreur d'implémentation.
Semantic Versioning 2.0.0
Référentiel · Tom Preston-Werner
La convention de numérotation MAJEUR.MINEUR.CORRECTIF des versions de dépendances qui facilite les mises à jour.
ISO/IEC/IEEE 14764:2022
Norme · ISO / IEC / IEEE
Les processus de maintenance logicielle et la définition de ses types : correctif, adaptatif, perfectif, préventif, et depuis 2022 additif.
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.