Idée principale

Presque toutes les exigences posées autour d'un développement se négocient contre l'enjeu de l'objet produit. Le niveau de tests attendu sur un petit outil interne jetable n'est pas celui d'un module de facturation ; la revue, la documentation, la stratégie de déploiement se dosent de la même façon, et c'est sain.

La sécurité ne se comporte pas ainsi, parce que son risque ne se mesure pas à l'importance de l'outil mais à ce à quoi il donne accès. Un écran interne bricolé qui interroge la base de production est une porte, quel que soit le sérieux qu'on lui accorde ; la fuite ne dépend pas de la durée de vie prévue de l'objet, et l'attaquant ne consulte pas la catégorie dans laquelle l'organisation l'avait rangé.

L'exigence de sécurité doit donc être posée hors de la grille de graduation, comme la seule ligne qui ne dépende pas de l'humeur du moment ni de l'enjeu déclaré.

Pourquoi c'est important

Cela évite qu'une politique d'assouplissement — justifiée et utile sur les tests, la revue et la documentation — n'emporte la sécurité par simple cohérence de raisonnement. C'est le glissement naturel : dès qu'on écrit « faible enjeu, faible formalisme », la sécurité tombe dans le même sac.

Cela rend aussi la règle applicable, parce que la sécurité est justement la ligne où l'outillage existe déjà : intégration continue, scanners, règles et pratiques tenues par les équipes de développement n'ont pas à être réinventées pour une production venue d'ailleurs.

Nuances et limites

L'affirmation vaut pour l'exigence, pas pour les moyens. Un outil isolé, sans données réelles et sans exposition réseau, n'appelle pas le même dispositif qu'un service exposé — mais l'écart porte sur la surface à protéger, pas sur le droit de ne pas la protéger.

Et une exigence non négociable n'est pas une exigence tenue : elle ne vaut que si elle est adossée à des contrôles automatiques, faute de quoi elle redevient une déclaration.

Questions ouvertes

• D'autres exigences se comportent-elles comme la sécurité — la conformité réglementaire, la traçabilité des accès, la réversibilité des écritures — ou l'exception est-elle vraiment unique ?