Quels outils et méthodes de revue de code utiliser pour auditer le code livré par une agence ?

En lançant vos outils statiques, ne regardez pas uniquement le respect des standards de code, activez aussi les règles SAST orientées sécurité. Les injections SQL, les failles IDOR (accès direct non sécurisé à un objet) et les manques de validation des entrées remontent très bien automatiquement. Regardez aussi le taux de couverture de tests : si l'agence n'a pas écrit de tests unitaires, refactorer ce code sera un calvaire.

L'année dernière, on a récupéré le backend mobile d'un projet payé 40.000 dollars. Les scanners automatiques étaient tous au vert parce que la syntaxe était nickel. Sauf que deux semaines après la mise en prod, la base de données s'est écroulée : l'agence n'avait mis aucune clé étrangère ni aucun index sur les tables relationnelles. Un outil automatique ne verra jamais ça.

Au moment de la reprise du code, on a payé 2.500 dollars à un architecte senior indépendant pour 15 heures d'audit approfondi. Il a débusqué 4 gros défauts d'architecture bloquants pour monter en charge et 8 failles d'autorisation flagrantes laissées par l'agence. C'est de loin l'argent le mieux rentabilisé du projet.

Ne vous fiez pas trop aux rapports des outils automatisés pour le travail d'agence. Parfois, les agences découpent les fonctions en mille morceaux pour faire du pseudo-clean code juste pour que les outils d'analyse ne crient pas, alors que la logique métier est un vrai plat de spaghettis. Ces outils ne valident pas le bon fonctionnement du code, ils vérifient seulement qu'il respecte les règles de syntaxe.

La toute première chose à faire dès demain : épluchez l'historique des versions du dépôt (git log). Est-ce que l'agence a tout pushé en panique sur les 3 derniers jours, ou est-ce qu'il y a eu des commits réguliers avec des messages clairs pendant 4 mois ? La rigueur dans le versioning en dit très long sur la qualité interne du code.

Checklist pour les livrables d'agence : 1) Des clés d'API ou mots de passe de services tiers ont-ils été oubliés en dur dans le code ? 2) Les licences des bibliothèques open source sont-elles compatibles avec votre usage commercial ? 3) Les étapes de déploiement et d'installation locale fonctionnent-elles de bout en bout dans une seule et même doc ?

vérifiez absoluument s'ils ont écrit des tests à mon avis mais genre les agences zappent souvent les tests unitaires sous prétexte de manque de temps et après vous modifiez une seule ligne de code et toute l'architecture s'effondre.

soyez un peu patient avec votre nouveeau développeur senior. reprendre le code de quelqu'un d'autre est le truc le plus frustrant au monde pour un dev. les outils automatisés permettent au moins d'éviter les attaques personnelles lors des débats en s'appuyant sur des métriques objectives.

C'est noté merci.

Je me pose aussi la question.

Je suis intéressé.

Beau travail. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

Je le note au cas où.

la solution qui semble bon marché fniit souvent par coûter cher puis lors de la prise de décision écrivez aussi le pire scénario pas seulement le meilleur.

quand on essaie de tout changer en même temps rien ne prend. si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Mon regard a changé après avoir vécu cela. Un code sans documentation d'installation ne vous appartient pas, même si vous l'avez.

Si vous écrivez le résultat ici cela aidera aussi d'autres personnes.

Je suis d'accord.

On en parle beaucoup, mais chez nous, cela ne s'est jamais passé ainsi. Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même.

À votre place, j'irais par cette voie.

Je suis passé par là, laissez-moi vous raconter. Un rapport d'avancement écrit hebdomadaire est bien plus utile que de demander des dates.

Chez nous aussi. Tous ceux qui se pressent sur outils de revue de code se heurtent au même obstacle.

Commencez par un petit test, ne vous engagez pas sur tout d'un coup. À votre place, j'irais par cette voie.