Audit de code source
Vous avez hérité d’un logiciel, vous hésitez entre le réparer et le refaire, ou vous voulez savoir si le code que vous payez tient la route. Un audit de code indépendant répond à ces questions avec des faits vérifiables, pas des impressions.
Qu’est-ce qu’un audit de code ?
Un audit de code est un examen structuré du code source, de la base de données et de l’infrastructure d’une application, mené par une équipe qui ne l’a pas écrite. Il produit un état des lieux documenté : ce qui est solide, ce qui est risqué, ce que ça coûtera de corriger.
Ce n’est pas une revue de code au sens quotidien du terme (la relecture entre développeurs avant une fusion). C’est un mandat ponctuel, indépendant, qui répond à une décision d’affaires : investir, racheter, refaire ou continuer.
Ce qu’un audit vous dit et que personne d’autre ne vous dira :
- Le niveau de risque réel de votre application en sécurité et en conformité.
- La quantité de dette technique accumulée, chiffrée en effort de correction.
- Si votre système peut absorber la croissance prévue des prochaines années.
- Ce qui explique les lenteurs et les bogues récurrents, au-delà des symptômes.
- Combien de temps il faudrait à une nouvelle équipe pour reprendre le code.
Ce que nous analysons
Trois axes, toujours les mêmes, parce que ce sont les trois façons dont un logiciel finit par coûter cher à son propriétaire.
Quand faire auditer votre code ?
Un audit se justifie quand une décision importante dépend de l’état du code et que personne dans l’organisation ne peut trancher de façon neutre. Les situations reviennent souvent :
La diligence raisonnable technique. Vous rachetez une entreprise dont la valeur repose sur sa plateforme : vous devez savoir ce que vous achetez vraiment avant de signer.
Le code est là, la connaissance est partie. L’audit établit ce qu’il reste, ce qui manque et combien de temps il faudra à une nouvelle équipe pour reprendre le volant.
La question la plus coûteuse à trancher au feeling. L’audit compare les deux scénarios avec des chiffres, puis vous choisissez en connaissance de cause.
Une intrusion, une fuite de données, un test d’intrusion raté. L’audit cherche les causes structurelles derrière le symptôme, pas seulement la porte utilisée.
Chaque nouvelle fonctionnalité prend plus de temps que la précédente. C’est la signature d’une dette technique arrivée au point où elle dicte le rythme.
Un audit préalable transforme une refonte en projet chiffré plutôt qu’en pari. C’est aussi la première étape de nos mandats de réécriture.
Notre processus d’audit
Un audit utile tient en quelques semaines et se termine par une décision, pas par un document de deux cents pages que personne n’ouvrira. Voici comment nous procédons.
Cadrage et accès
Nous définissons ensemble la question à laquelle l’audit doit répondre : vendre, racheter, refaire, sécuriser, accélérer. Nous obtenons ensuite l’accès au dépôt de code, à une copie de la base de données et à l’environnement d’hébergement.
Analyse automatisée
Nous passons le code dans nos outils d’analyse statique et de détection de vulnérabilités : complexité, duplication, couverture de tests, dépendances vulnérables, versions en fin de vie. Cette passe donne la carte, pas le verdict.
Revue manuelle ciblée
Nous lisons en profondeur les zones qui comptent : l’authentification, les permissions, les modules financiers, les intégrations externes et les parties du code que les outils ont signalées. C’est ici que se trouvent les vrais risques.
Entrevues avec vos équipes
Une heure avec les personnes qui utilisent ou maintiennent le système révèle des contraintes qu’aucun outil ne voit : les contournements quotidiens, les modules que plus personne n’ose toucher, les promesses jamais livrées.
Rapport et plan d’action priorisé
Nous livrons un rapport lisible par un dirigeant comme par un développeur, avec chaque constat classé par gravité, chiffré en effort et ordonné par retour sur investissement. Nous le présentons de vive voix et nous répondons aux questions.
Ce que vous recevez
Un audit ne vaut que par ce qu’il permet de décider. Nos livrables sont conçus pour être utilisés en comité de direction dès la semaine suivante.
Un rapport d'audit complet
Sommaire exécutif en une page, puis le détail technique : architecture, sécurité, performance, qualité du code, infrastructure. Chaque constat est appuyé par un extrait de code ou une mesure, jamais par une opinion.
Une matrice de risques
Chaque problème classé par gravité et par probabilité, avec son impact d'affaires exprimé en langage clair. Vous voyez immédiatement ce qui doit être corrigé cette semaine et ce qui peut attendre l'an prochain.
Un plan d'action chiffré
Les correctifs recommandés, ordonnés par retour sur investissement, avec une estimation d'effort pour chacun. Vous pouvez le confier à votre équipe interne, à votre fournisseur actuel ou à nous.
Une rencontre de restitution
Nous présentons les conclusions à vos parties prenantes, techniques et d'affaires, et nous répondons aux questions. Un rapport qu'on ne peut pas discuter ne sert à rien.
Ce que disent nos clients
Questions et réponses
Entre une et quatre semaines dans la grande majorité des cas. La durée dépend de la taille du code, du nombre d’intégrations et de la profondeur demandée. Un audit de cadrage, pour trancher entre réparer et refaire, se boucle souvent en une semaine.
Le prix suit l’effort, donc la taille et la complexité du système. C’est un mandat à portée fixe : nous convenons du périmètre et des livrables avant de commencer, et le montant ne bouge pas. Comparé au coût d’une refonte lancée sur une mauvaise hypothèse, c’est la dépense la plus rentable du projet.
Nous auditons principalement les applications PHP (Laravel, Symfony, CodeIgniter, Zend, CakePHP, code sans framework), JavaScript et TypeScript (Node, Vue, React), ainsi que les bases de données relationnelles MySQL, MariaDB et PostgreSQL. Notre page technologies détaille notre couverture.
Oui, un audit sérieux exige de lire le code. Nous signons une entente de confidentialité avant tout accès, nous travaillons sur une copie isolée et nous détruisons les copies à la fin du mandat. Une base de données anonymisée suffit dans la majorité des cas.
C’est même le cas le plus fréquent. Notre indépendance est la valeur du mandat : nous n’avons pas écrit ce code et nous n’avons rien à défendre. Le rapport reste factuel et vous appartient, y compris si vous choisissez de rester avec votre fournisseur actuel.
Non, et ce serait suspect qu’il le fasse toujours. Une partie de nos audits conclut que le système est sain et qu’il faut simplement corriger quelques points précis. Quand la refonte ou la modernisation s’impose, le rapport explique pourquoi, chiffres à l’appui.
Vous décidez. Vous pouvez confier le plan d’action à votre équipe interne, à votre fournisseur actuel, ou nous demander de l’exécuter dans le cadre d’un mandat de support et maintenance. Le rapport est le vôtre, sans obligation de suite.
Non, les deux sont complémentaires. Un test d’intrusion attaque l’application de l’extérieur et prouve qu’une faille est exploitable. L’audit de code lit l’intérieur et trouve les faiblesses structurelles qu’une attaque n’aura pas encore trouvées. Sur les systèmes sensibles, faites les deux.