Prévu vs. mis en œuvre : analyser l'écart

Objectif

Un linter analyse le code en vase clos. Il peut vous indiquer que le code est cohérent en soi ; il ne peut pas vous dire si le code fait ce que vous aviez prévu, car il ne dispose d’aucun modèle de votre intention. Les failles de sécurité et d’exactitude les plus graves se cachent dans cet écart : une autorisation documentée mais jamais appliquée, un point de terminaison « réservé au cron » que n’importe qui peut appeler, un champ marqué comme « public uniquement » qui divulgue des données privées.

Cette compétence consiste à identifier cet écart. C’est ce qui fait toute la différence : elle ne fonctionne que lorsque l’intention a d’abord été consignée par écrit (voir la compétence « artefacts de livraison »), et c’est précisément pour cette raison que les outils standard ne peuvent pas la reproduire.

Contexte

Utilisez cette compétence lorsqu’une intention documentée existe — permissions.md, architecture.md, variables.md, etc. Si ces documents sont absents ou obsolètes, cette absence constitue en soi la première constatation : vous ne pouvez pas auditer une intention que vous n’avez jamais consignée. Il est recommandé de documenter d’abord, puis d’auditer.

Méthode

1. Définissez l’intention. Considérez le /documentation/*.md ensemble de spécifications comme la source de référence de ce qui devrait être vrai : qui peut accéder à quoi, quelles limites sont fiables, quelles données sont publiques. Considérez la documentation comme des affirmations à vérifier, et non comme des preuves.

2. Recueillez des preuves de mise en œuvre. Lisez le code qui applique (ou ne parvient pas à appliquer) chaque affirmation. Une preuve est un fichier et une ligne cités — le contrôle d’autorisation réel, le filtre de requête réel, le nettoyeur réel. « C’est probablement géré en amont » n’est pas une preuve ; le chemin de code, lui, en est une.

3. Comparez les affirmations au code, une limite à la fois. Pour chaque règle documentée, posez-vous la question suivante : un point d’application la met-il réellement en œuvre, sur le serveur, sur chaque chemin d’accès ? Méfiez-vous des commentaires tels que « à usage interne uniquement », « réservé à l’administrateur » ou « validé ailleurs » — vérifiez-les dans le code.

4. Classez chaque divergence selon son importance. Une divergence est importante lorsqu’en la franchissant, un acteur réel peut accéder à des données, à de l’argent, à l’infrastructure ou à un autre locataire auquel il ne devrait pas avoir accès. Elle n’a pas d’importance lorsque la seule personne concernée est l’acteur lui-même, sur ses propres données. Écartez les divergences superficielles ; conservez celles qui franchissent les limites.

5. Évitez les constatations vagues. Chaque constatation doit préciser : l’intention documentée (citez la documentation), la réalité mise en œuvre (citez le code), l’attaquant et la victime, ainsi que la correction concrète. Si vous ne pouvez pas citer les deux aspects de l’écart, il s’agit d’une question à examiner, et non d’un constat à signaler.

Ce qui compte

• Intention : une règle, une limite, un périmètre ou une classification publique/privée documentés.
• Preuve de mise en œuvre : un point d’application cité (ou son absence démontrable) dans le code.
• Un décalage significatif : la documentation dit une chose, le code en fait une autre, et cette différence franchit une limite en matière de confiance, de coût, de données ou de locataire.

Remarques

• « Documenté mais non appliqué » constitue un constat en soi — classez-le en fonction de ce que la mise en évidence de cet écart révèle.
• « Non documenté mais appliqué » est généralement acceptable, mais signalez-le : la documentation est désormais obsolète, ce qui affaiblit le prochain audit.
• Cette méthode alimente les audits de sécurité et de performance ; elle ne remplace pas leur analyse au niveau des composants, mais y ajoute l’axe de l’intention qui leur fait défaut.
• Ne fabriquez jamais d’intention pour créer une lacune. Si la documentation est muette, indiquez-le.