Un audit de code pour savoir ce que vaut vraiment votre logiciel.
Votre prestataire dit qu’il faut tout réécrire. Vos développeurs disent qu’il leur faut du temps. La direction veut une date. Un audit de code tranche sur les faits : des ingénieurs lisent le code, le font tourner, vérifient sa sécurité et ses données, et échangent avec ceux qui le maintiennent. Vous recevez un rapport écrit et un plan applicable, avec nous ou avec n’importe qui d’autre.
- Ce que vous recevez
- Un rapport écrit, les risques classés, et une recommandation pour chaque partie du logiciel.
- Périmètre et prix
- Fixés avant de commencer, selon la taille du code et les questions à trancher.
- La suite
- Votre décision. Le plan s’applique avec votre équipe, avec nous ou avec un autre prestataire.
Ce que vous recevez à chaque étape de l’audit.
Avant de commencer
Fixer les questions
Réécrire ou non, reprendre le code d’un prestataire, racheter une société, passer une revue de sécurité : l’audit se construit autour de la décision à prendre. Vous recevez un périmètre écrit et un prix ferme.
Revue
Lire, exécuter, mesurer
Un accès en lecture seule au code et aux serveurs, une analyse automatique, puis une lecture ligne à ligne des parties qui comptent. Le logiciel est compilé et déployé comme le fait votre équipe.
Entretiens
Écouter ceux qui savent
Développeurs, utilisateurs et personne qui déploie. Une bonne part de ce qu’un audit découvre n’a jamais été écrite dans le dépôt : elle est dans les têtes.
Rapport
Décider sur les faits
Un rapport écrit, les risques classés selon leur impact, et pour chaque partie du logiciel une recommandation : garder, corriger, remanier ou reconstruire, avec l’effort que demande chaque option.
Qu’est-ce qu’un audit de code ?
Un audit de code est une revue indépendante d’une application : code source, architecture, dépendances, sécurité, tests et déploiement. Il dit dans quel état est réellement le logiciel, quels risques il porte et ce que demanderait chaque option : le garder, le corriger ou le reconstruire. Un audit utile se termine par un plan priorisé, étayé de preuves qu’un ingénieur peut vérifier.
La plupart des audits logiciels sont demandés à un tournant. Un prestataire s’en va, une réécriture est sur la table, une société va être rachetée, un incident a entamé la confiance. Chaque fois, quelqu’un doit décider avec de l’argent en jeu, et ceux qui sont les plus proches du code sont rarement neutres.
Le sauvetage d’un projet logiciel commence de la même façon. Quand un projet s’enlise, l’audit distingue ce qui ne va pas dans le code de ce qui ne va pas autour : priorités, organisation, savoir détenu par une seule personne. Parfois, le code est le moindre des problèmes, et le rapport le dit.
Quand un audit de code change la décision.
Le premier est un projet réel ; le nom du client reste confidentiel et les faits sont ceux publiés à la livraison. Les deux autres décrivent les moments où l’on nous appelle le plus souvent.
Projet réel : une entreprise de génération de leads B2B, où le problème se trouvait autour du code
AvantL’équipe produit ne livrait plus. Les sprints ressemblaient à des comités de planification qui ne décidaient rien, et la direction ne savait plus quoi demander à ses développeurs.
AprèsAvant de toucher au code, le cadre a été reposé : un carnet de demandes priorisé sur la valeur, des blocages remontés sous 24 heures, des démonstrations ouvertes à tous. La base JavaScript a été gardée telle quelle, et l’équipe livre de nouveau sous la conduite d’un product owner interne.
Avant de reprendre le code d’un prestataire
AvantL’agence qui a construit le logiciel s’en va, et personne ne sait ce qui est remis.
AprèsLa liste claire de ce qui marche, de ce qui est fragile et de ce qui manque, avant de signer avec l’équipe suivante.
Avant de décider une réécriture
AvantUn devis de réécriture sur la table, et aucun avis indépendant sur sa nécessité.
AprèsChaque partie du logiciel évaluée à part, pour ne reconstruire que ce qui doit l’être.
De quoi dépend le prix d’un audit de code.
Relire une application écrite dans un seul langage et auditer un ensemble de services construits par trois prestataires sont deux travaux différents. Le périmètre et le prix sont fixés par écrit avant de commencer, à partir de ces éléments.
Lire le guide des prix du logiciel sur mesure, avec les fourchettes du marché- 01La taille du code, et le nombre d’applications ou de services.
- 02Le nombre de langages, de frameworks et de bases de données en jeu.
- 03La profondeur de la revue de sécurité.
- 04Les serveurs, le déploiement et les données, dans le périmètre ou non.
- 05L’accès aux personnes qui connaissent le logiciel.
Ce que vérifie un audit de code, et pourquoi ça vous concerne.
Sept domaines, chacun lié à un risque pour l’entreprise. Le rapport note chacun et dit lesquels traiter en premier.
| Critère | Ce qu’on examine | Le risque s’il est faible |
|---|---|---|
| Architecture | Le découpage du logiciel, ce qui dépend de quoi | Chaque modification touche tout, et coûte plus cher chaque année |
| Qualité du code | Lisibilité, duplication, complexité des parties critiques | Seuls les auteurs d’origine peuvent le modifier sans risque |
| Dépendances et versions | Frameworks, bibliothèques et langages, et leur statut de maintenance | Des failles que personne ne corrige, des mises à niveau forcées |
| Sécurité | Authentification, droits d’accès, secrets, contrôle des saisies, failles connues | Une fuite de données, et les obligations RGPD qui suivent |
| Tests et déploiement | Tests automatiques, compilation et mise en production, retour arrière | La peur de livrer, et des incidents en production |
| Données | Structure de la base, cohérence, sauvegardes, données personnelles | Des chiffres faux, un historique perdu, une migration qui échoue |
| Savoir | Documentation, et qui sait quoi | Le logiciel s’arrête le jour où une personne s’en va |
Audit de code : les questions qu’on nous pose
Combien de temps dure un audit de code ?
Cela dépend de la taille du code et des questions à trancher. On fixe avec vous le périmètre et le prix, par écrit, avant de commencer. Un audit ciblé sur une application est bien plus court que la revue de plusieurs services construits par des prestataires différents.
De quoi avez-vous besoin de notre côté ?
Un accès en lecture seule au dépôt de code et, si c’est dans le périmètre, aux serveurs et à une copie de la base. Puis quelques heures avec ceux qui construisent, déploient et utilisent le logiciel. On travaille sous accord de confidentialité, et vous retirez nos accès à la fin de l’audit.
Un audit de code, est-ce la même chose qu’un test d’intrusion ?
Non. L’audit lit le code et sa configuration pour trouver, entre autres risques, les faiblesses de sécurité. Le test d’intrusion attaque le logiciel en fonctionnement depuis l’extérieur, comme le ferait un intrus. Les deux se complètent, et l’audit peut vous dire si un test d’intrusion vaut la peine ensuite.
Pouvez-vous auditer le code d’une autre agence ?
Oui, c’est le cas le plus fréquent. Le rapport reste factuel sur le code et l’organisation, pour pouvoir être partagé avec le prestataire concerné. Le but est une décision pour vous, et un regard juste sur le travail fait.
Et si l’audit recommande une réécriture ?
Le rapport dit quelles parties en ont besoin, et pourquoi, avec l’effort que demande chaque option. Souvent, seule une partie du logiciel doit être reconstruite. Vous restez libre de mener le plan avec votre équipe, avec nous ou avec un autre prestataire.
Sommes-nous tenus de continuer avec vous après l’audit ?
Non. Le rapport est à vous, et il est écrit pour servir à n’importe qui. Si vous voulez qu’on mène l’étape suivante, maintenance ou modernisation, son périmètre et son prix sont fixés par écrit avant de démarrer.
Un audit à montrer à votre direction, et à votre prestataire.
Sécurité et donnéesUne preuve derrière chaque constat.
Chaque risque renvoie au fichier, à la dépendance ou à la mesure dont il vient, pour que vos ingénieurs puissent le vérifier.
Lecture seule, sous confidentialité.
On ne modifie jamais votre code pendant un audit, et les accès prennent fin avec la mission.
Écrit pour deux lecteurs.
Une synthèse sur laquelle un dirigeant peut décider, et le détail technique sur lequel un développeur peut agir.
Aucune réécriture à vendre.
La recommandation se fait partie par partie, et garder le logiciel tel quel reste une option sur la table.
Dans la même famille
Après l’audit
- Modernisation applicative Quand l’audit montre que le logiciel doit évoluer.
- Tierce maintenance applicative Quand l’audit montre qu’il faut l’entretenir.
- Logiciel sur mesure Quand une partie doit être construite à neuf.
- Application métier Les outils internes qu’on construit et qu’on audite.
- Audit IA Quand votre question porte sur l’IA et où elle rapporte.
- Prix du logiciel sur mesure Les fourchettes du marché, avec leurs sources.
- La dette technique, expliquée Comment elle se mesure, et ce qu’un audit ajoute aux outils.
Que décideriez-vous si vous connaissiez l’état réel de votre code ?
Parlez-nous du logiciel et de la décision qui vous attend. On vous répond sous un jour ouvré pour caler un échange gratuit de 30 minutes, dont vous repartez avec les questions que l’audit devra trancher.