Audit de code avec l’IA : quoi vérifier, et quand en avez-vous besoin ?

Deux questions, pas une

Un audit répond à deux questions différentes, et la plupart des outils n’en posent qu’une.

1. Avons-nous construit ce qui était convenu ? Le produit a des exigences, écrites quelque part. Sont-elles toutes implémentées ? L’une d’elles a-t-elle changé en douce ? Quelque chose a-t-il été abandonné sans que personne ne l’ait décidé ?
2. Peut-on le mettre sans risque entre les mains de clients ? Un compte peut-il voir les données d’un autre ? Y a-t-il des secrets dans le dépôt ? Un nouvel essai de paiement débite-t-il deux fois ?

La seconde question attire l’essentiel de l’attention, car les failles de sécurité coûtent cher et se voient. La première est plus souvent ignorée, et pour un petit produit c’est généralement là que se trouvent les surprises : la fonctionnalité promise à un client qui n’a jamais été construite, ou l’exigence reformulée après validation pour que le produit « passe ».

Ce qu’il faut pour la première question

Impossible de vérifier un produit par rapport à des exigences qui n’existent pas, ou que personne ne peut tester. La première moitié d’un audit dépend donc d’un travail fait bien plus tôt :

• Des exigences avec des clés, par exemple REQ-014, qui ne changent jamais, pour que le travail puisse y être rattaché.
• Des critères d’acceptation pour chacune : comment quelqu’un la vérifierait sur le produit en fonctionnement.
• Une version figée de ce qui a été convenu. Si les exigences restent modifiables après validation, un audit « par rapport aux exigences » est un audit par rapport à ce qu’elles disent aujourd’hui.

Une fois ces éléments en place, les vérifications sont simples. Chaque exigence Must a un travail terminé qui lui correspond. Chaque critère d’acceptation est satisfait sur le produit en ligne. Les exigences modifiées après validation sont signalées avec l’ancienne et la nouvelle formulation. Les exigences abandonnées sont consignées comme des décisions, pas supprimées.

Ce qu’il faut pour la seconde question

Pour un petit produit web ou mobile, une revue pragmatique de la sécurité et de la fiabilité couvre six domaines :

• Contrôle d’accès. Chaque route qui touche à des données privées vérifie la session. Les actions d’administration vérifient un rôle, pas seulement que l’utilisateur est connecté. Modifier un identifiant dans une URL ne permet pas d’atteindre les données d’un autre compte. C’est ici que se trouvent la plupart des constats graves dans les petits produits.
• Secrets. Aucune clé ni aucun jeton dans le dépôt ou son historique. Aucun secret serveur exposé au navigateur via une variable d’environnement publique. Les identifiants divulgués ont été renouvelés.
• Dépendances. Les vulnérabilités connues sont vérifiées dans une vraie base d’avis de sécurité, comme npm audit ou OSV, et les identifiants des avis sont consignés.
• Traitement des entrées. Requêtes paramétrées, aucune exécution de code dynamique à partir des saisies utilisateur, sorties échappées, fichiers envoyés validés, requêtes côté serveur vers des URL fournies par l’utilisateur restreintes.
• Flux financiers. Les traitements de paiement sont idempotents, les signatures des webhooks sont vérifiées, les montants sont calculés côté serveur, et les crédits ou remboursements ne peuvent pas être dépensés deux fois en cas de requêtes simultanées.
• Exploitation. Les erreurs remontent dans un outil de monitoring que quelqu’un consulte, des sauvegardes existent et une restauration a été testée, les migrations sont appliquées avant le code qui en dépend.

Et une vérification de plus, facile à oublier : le produit est en ligne. L’audit d’un produit que personne hors de l’équipe ne peut atteindre n’est pas terminé.

Où l’IA aide

L’IA est réellement utile dans un audit, à des endroits précis :

• Lire rapidement une grosse base de code et indiquer où regarder : chaque gestionnaire de route, chaque endroit où un prix est calculé, chaque appel qui récupère une URL.
• Trier. Classer une longue liste de constats en commençant par ce qui coûte de l’argent ou expose des données.
• Rédiger les étapes de reproduction et des correctifs suggérés pour un constat déjà établi.
• Expliquer un constat à la personne qui doit le corriger, dans les termes de son propre code.

Où l’IA gêne

Le piège, c’est un audit fait des opinions d’un modèle. Si on lui demande « ce code est-il sécurisé ? », un modèle produira une liste assurée, en partie juste, en partie plausible et fausse, le tout présenté de la même façon. Un constat invérifiable est pire que pas de constat du tout : le traquer prend du temps, et l’équipe apprend à ignorer le rapport.

Les règles d’un audit assisté par l’IA sont donc simples :

• Pas de preuve, pas de constat. Chaque constat a un emplacement (fichier et ligne, ou une route), une preuve qui montre le problème et des étapes pour le reproduire. Sans preuve, il n’y a pas de constat.
• Les constats viennent de vérifications, pas d’impressions. Les avis sur les dépendances viennent d’une base d’avis de sécurité, pas de la mémoire du modèle. Les constats de contrôle d’accès viennent du fait d’avoir réellement modifié un identifiant et observé le résultat.
• Une identité stable. Donnez à chaque constat une empreinte, pour qu’une nouvelle exécution de l’audit vous dise ce qui a été corrigé au lieu de produire un nouveau pavé de texte.
• Un verdict, pas une humeur. L’audit est réussi quand il ne reste aucun constat critique ou élevé ouvert et que le produit est en ligne. Sinon, c’est une itération de plus.

Quand en avez-vous besoin

Une petite équipe n’a pas besoin d’un programme d’audit continu. Elle a besoin d’un audit aux moments où la réponse compte :

• Avant un lancement public ou une soumission sur un store d’applications. C’est le dernier moment peu coûteux pour trouver une faille de contrôle d’accès.
• Quand un travail externe vous est livré. Un prestataire, un studio ou un agent de code a construit quelque chose à partir de vos exigences. C’est précisément le moment où la question « avons-nous obtenu ce qui était convenu ? » appelle une réponse.
• Avant une due diligence, ou quand vous reprenez la base de code de quelqu’un d’autre.
• Après des changements importants touchant l’authentification, les paiements ou l’accès aux données.

Entre ces moments, une habitude plus légère suffit : gardez des exigences avec des clés, citez ces clés dans les commits et les pull requests, et revérifiez les flux financiers dès qu’ils changent.

Ce que fait Atrix AI, et ce qu’il ne fait pas

Soyons clairs sur le périmètre : Atrix AI n’analyse pas votre code. Les vérifications de sécurité et de fiabilité ci-dessus sont à votre charge, à la main, avec les outils cités, ou par un relecteur de confiance. Atrix AI prend en charge la partie de l’audit à laquelle un espace de travail peut répondre honnêtement, ainsi que le suivi de tout le reste.

La première question : avons-nous construit ce qui était convenu ? Dans Atrix AI, vous acceptez vos exigences et les figez sous forme de référence numérotée, qui conserve la formulation exacte de chaque exigence, ainsi que le PRD et les documents sources, tels qu’ils étaient. L’audit des exigences indique ensuite, pour chaque exigence de la référence, si du travail existe, est en cours ou est terminé. Il signale les exigences dont la formulation a changé ou qui ont été abandonnées après le gel, ainsi que les documents figés modifiés depuis. Une exigence intégrée à une référence ne peut pas être supprimée, seulement marquée Won’t : rien ne disparaît en silence. Chaque état est calculé à partir de vos données, pas de l’avis d’un modèle.

Traçabilité. Les exigences portent des clés permanentes. Quand vous confiez le développement à un agent de code, le dossier de passation du mode Develop contient les documents et les clés, et demande que les clés soient citées dans les commits et les pull requests. Un auditeur peut ainsi rattacher chaque travail à sa raison d’être. L’agent IA rédige les exigences et planifie le travail ; ce sont des personnes qui décident de ce qui est convenu.

Suivi des constats. Chaque constat de votre audit peut être enregistré comme un ticket avec une priorité, dans le même projet que les exigences concernées, et les exigences acceptées sans travail associé peuvent être découpées en tickets. La seconde moitié de l’audit se fait en dehors d’Atrix ; ses résultats n’ont pas à finir dans un tableur.

Pour les vérifications elles-mêmes, utilisez la checklist d’audit de code gratuite. Elle comprend un journal des constats avec, pour chaque ligne, la gravité, l’emplacement, la preuve, les étapes de reproduction et un correctif suggéré.

En bref

Un audit de code utile vérifie le produit par rapport à des exigences convenues et testables, puis vérifie qu’il est sûr et en ligne. L’IA accélère la lecture, le tri et l’explication. Elle ne doit jamais être, à elle seule, la source d’un constat. Commencez par des exigences vérifiables, et le reste de l’audit devient bien plus simple.