Audit de code : ce qu’un fondateur non technique achète vraiment

Votre développeur vient de démissionner, ou l’agence que vous avez payée réclame la seconde moitié du règlement. Il vous faut quelqu’un pour vous dire si le code tient la route. Voici ce qu’est vraiment cette inspection, qui devrait la mener, et comment lire le résultat quand on ne sait pas lire le code.

Le message arrive tôt ou tard dans la boîte de beaucoup de fondateurs, presque toujours un dimanche soir. Le développeur principal a démissionné. Ou le freelance d’il y a deux ans ne répond plus. Ou une agence réclame la dernière facture et quelque chose au fond de vous dit que ce qu’ils ont construit tient avec du scotch. Vous transférez le lien du dépôt à la seule personne technique en qui vous avez confiance et vous écrivez la phrase que tout le monde écrit : tu peux y jeter un œil et me dire si c’est bon ?

Cette demande a un nom. Un audit de code est une revue structurée d’une base de code, menée par quelqu’un qui ne l’a pas écrite, pour vous dire dans quel état elle est : à quel point elle est exposée aux failles de sécurité, à quel point elle sera difficile à faire évoluer, si elle fait vraiment ce qu’elle devrait, et quelle part dépend d’une seule personne susceptible de partir. C’est le deuxième avis que vous demandez avant de confier l’avenir de votre entreprise à un tas de logiciel. Le terme sonne technique, et le rapport le sera, mais la décision de commander un audit est une décision de business, et elle atterrit presque toujours sur le bureau de quelqu’un qui ne peut pas lire une ligne du code en question. Cette personne, c’est souvent le fondateur. Ce texte est pour elle.

Ce qu’est vraiment un audit de code

Retirez l’outillage et le jargon, et un audit de code répond à une question que le fondateur se pose pour de vrai : si je continue à construire là-dessus, sur quoi je m’appuie ?

Un auditeur lit le code source, lance des scanners automatiques, observe comment le code est organisé, vérifie ce qui est testé et ce qui ne l’est pas, et examine comment le système est mis en production et qui a les clés. Puis il rédige. Les bons rédigent deux fois : une annexe technique pour celui qui héritera du code, et un résumé en langage clair pour la personne qui a payé l’audit. Si vous n’avez reçu que l’annexe technique, vous avez reçu la moitié de ce que vous avez acheté.

Il est utile de dire ce qu’un audit de code n’est pas. Ce n’est pas une revue du produit, donc il ne vous dira pas si le produit est bon. Ce n’est pas un test d’intrusion, même s’il en recoupe une partie. Et ce n’est pas la même chose que la technical due diligence, la version qu’un acquéreur ou un investisseur mène sur une entreprise dans laquelle il s’apprête à mettre de l’argent. La mécanique se ressemble. Le contexte, non. La due diligence demande « est-ce que je fais cette opération ? ». L’audit de code demande « est-ce que je peux faire confiance au code que j’ai déjà payé ? ». On audite sa propre maison. On fait une due diligence sur celle d’un autre.

Les quatre choses qu’un audit examine vraiment

Cherchez un peu et on vous dira qu’il existe « quatre types d’audit », d’ordinaire une liste de sigles de conformité comme SOC 2 et HIPAA. Pour un fondateur non technique qui construit un vrai produit, ce cadrage est presque entièrement du bruit. Voici les quatre choses qui comptent, dans l’ordre où elles ont tendance à faire mal.

Sécurité. Un inconnu peut-il entrer, lire les données de vos clients ou débiter leurs cartes ? C’est ici que l’auditeur vérifie comment les mots de passe sont stockés, comment le système décide qui a le droit de faire quoi, et si les trous évidents sont ouverts. C’est la partie à laquelle tout le monde pense en premier, et pour une fintech ou une healthtech c’est la partie qui peut tuer l’entreprise.

Maintenabilité. À quel point ce code sera-t-il difficile à modifier dans six mois ? Un système peut être parfaitement sécurisé et rester un marécage : sans structure, sans tests, chaque changement risquant d’en casser trois autres ailleurs. La maintenabilité est le tueur silencieux, parce qu’elle n’apparaît pas comme une crise. Elle apparaît comme chaque nouvelle fonctionnalité qui prend trois fois plus de temps que la précédente. Ce que l’auditeur mesure ici, c’est, en clair, votre dette technique : les intérêts que vous paierez plus tard pour les raccourcis pris maintenant.

Exactitude. Fait-il ce qu’il devrait faire, et comment le savez-vous ? C’est la question de la couverture de tests. Du code sans tests automatiques n’est pas forcément faux, mais personne ne peut le modifier en confiance, parce qu’il n’y a pas de filet sous le trapèze. Un auditeur vous dira quelle part du système est vérifiée automatiquement et quelle part repose sur quelqu’un qui clique un peu partout en croisant les doigts.

Risque opérationnel. Que se passe-t-il à 2 heures du matin quand ça casse, et qui sait réparer ? Cela couvre la mise en production, l’existence de sauvegardes, l’endroit où vivent les secrets, et le nombre de personnes qui comprennent l’ensemble. Si la réponse à la dernière est « une », vous n’avez pas une base de code, vous avez un otage. C’est le même problème qu’un bus factor de un, et l’audit est souvent la première fois qu’un fondateur le voit écrit noir sur blanc.

Un vrai audit note les quatre. Si le rapport ne parle que de sécurité, vous avez acheté un scan de sécurité et quelqu’un l’a appelé audit.

Pourquoi les fondateurs finissent par en avoir besoin

Personne ne se réveille en voulant un audit de code. On vous y pousse. D’après notre expérience, le déclencheur est presque toujours l’une de quatre scènes.

La première, c’est le développeur qui démissionne. Votre unique ingénieur pose sa démission, et le produit entier devient soudain un actif que personne dans l’équipe ne sait lire. L’audit vous dit la profondeur du trou avant que vous recrutiez pour le combler.

La deuxième, c’est le freelance qui disparaît. Vous avez livré une version il y a deux ans avec un développeur indépendant ou un petit atelier, la relation s’est éteinte, et vous voulez maintenant construire sur ce qui reste. Vous n’avez aucune idée de si vous agrandissez une maison ou une tente.

La troisième, c’est l’acquisition. Vous rachetez une petite entreprise, ou un actif à l’intérieur d’une, et le code vient avec. Ici audit et due diligence se confondent, mais les questions sont les mêmes : qu’est-ce que j’emporte vraiment.

La quatrième, c’est l’intuition. Votre prestataire actuel réclame plus d’argent ou plus de délai, les explications se sont mises à ressembler à la météo, et vous voulez une lecture indépendante avant de signer quoi que ce soit d’autre. C’est le déclencheur le plus sain, parce que vous agissez avant la crise plutôt qu’après.

Les quatre partagent une forme. Quelqu’un qui décrit l’entreprise avec une précision totale ne peut pas évaluer la chose sur laquelle l’entreprise tourne, et l’écart est enfin devenu assez coûteux pour qu’on paie afin de le combler.

Qui devrait le mener, et qui ne devrait jamais

Voici la règle qui compte le plus, et celle dont les prestataires vous dissuaderont discrètement : ceux qui ont écrit le code ne devraient jamais être ceux qui l’auditent. On ne demande pas à l’électricien d’inspecter sa propre installation. Toute la valeur d’un audit tient dans le regard extérieur, et un regard extérieur qui est aussi l’auteur n’est qu’un point d’avancement dans une plus jolie police.

Cela élimine trois options tentantes. Cela élimine l’agence qui a construit la chose, qui bien sûr vous dira que c’est solide. Cela élimine le développeur sur le départ, dont le résumé sera façonné par la manière dont se passe la sortie. Et cela élimine d’ordinaire votre prochaine recrue, parce que demander à un candidat de bénir le code dont il s’apprête à hériter le met dans une position impossible dès le premier jour.

Ce que vous voulez, c’est un ingénieur senior neutre ou un petit cabinet qui fait cela pour vivre et ne veut pas le contrat de reconstruction ensuite. Cette dernière clause est l’importante. Un auditeur qui vend aussi du développement a une raison de juger la base de code irrécupérable. Demandez franchement, avant de l’engager : si cet audit conclut que le code est bon, vous êtes payé pareil ? La réponse vous dit si vous achetez un avis ou un argumentaire de vente. Chez Pixel Breeders, nous avons mené des audits où le constat honnête était « c’est en meilleur état que vous ne le croyez, dépensez l’argent en fonctionnalités ». Un bon auditeur accepte de se convaincre de moins de travail, et ceux qui n’y arrivent pas sont précisément ceux qu’il faut éviter.

Combien de temps ça prend et combien ça coûte

Pour une base de code typique de stade précoce, un produit, deux ou trois ans d’historique, une petite équipe, un vrai audit prend entre quelques jours et deux semaines. Une revue ciblée uniquement sur la sécurité peut tenir en trois ou quatre jours. Un audit complet des quatre fronts sur un système de taille notable, c’est une à deux semaines de temps senior, parfois plus si la configuration de déploiement est un mystère à reconstituer à la main.

Le coût suit cela directement, parce que vous achetez des heures senior, pas un abonnement à un outil. Les scanners automatiques sont bon marché, certains gratuits, et un prestataire qui s’appuie entièrement dessus vous facturera étonnamment peu. La partie chère et précieuse, c’est une personne qui a vu cent bases de code en train de lire la vôtre et de vous dire lesquels des deux cents problèmes signalés par le scanner comptent vraiment. Prévoyez quelques milliers pour une revue bien cadrée et l’ordre des dizaines de milliers pour un audit minutieux d’un système plus gros. Si on vous propose un « audit complet » pour quelques centaines, c’est un outil qui tourne et vous envoie sa sortie par e-mail, et ça, vous le faites vous-même.

Une chose qui mérite d’être payée : une clause de revérification. Un bon audit se termine par une liste de correctifs hiérarchisée. Pouvoir faire revenir l’auditeur pour confirmer que les critiques ont été traités, un mois plus tard, vaut plus que le rapport initial, parce que cela boucle la boucle au lieu de vous laisser avec un PDF et une prière.

Lire le rapport quand on ne sait pas lire le code

C’est la partie sur laquelle presque personne n’écrit, et c’est celle dont le fondateur a vraiment besoin. L’audit revient. Il a un tableau de sévérité, sans doute en couleurs, avec des mots comme critique, élevé, moyen, faible. Vous ne pouvez pas évaluer le code, mais vous pouvez parfaitement mener la décision, parce que la sévérité se traduit proprement en langage de business.

Critique veut dire stop. Des données clients sont exposées, ou de l’argent peut bouger d’une façon qui ne devrait pas. Ceux-là se corrigent avant que la prochaine fonctionnalité parte, point final, sans négociation. Élevé veut dire planifie-le. C’est un risque réel ou un vrai poids sur l’équipe, et ça passe en tête de file, mais ça n’arrête pas la chaîne ce soir. Moyen et faible sont le backlog. Réels, bons à connaître, pas de quoi paniquer. L’erreur que commettent les fondateurs est de traiter une longue liste de moyens comme un incendie à cinq alarmes. Une longue liste de moyens, c’est normal. Toute base de code qui est déjà partie en production en a une. Ce que vous cherchez, c’est le nombre de critiques et d’élevés, et s’ils se concentrent dans les parties du système qui touchent à l’argent et à l’identité.

Et puis il y a cette ligne, tout en bas, qui mérite son propre paragraphe, parce que c’est là que les fondateurs perdent le plus d’argent.

Le piège de la réécriture

Tôt ou tard un audit, ou la personne qui le livre, arrive à une recommandation qui sonne décisive : c’est trop abîmé, vous devriez tout reconstruire de zéro. Parfois c’est vrai. Bien plus souvent c’est le conseil le plus cher du bâtiment, et il vaut la peine de s’en méfier, surtout quand celui qui le donne serait précisément celui qui serait payé pour faire la reconstruction.

Une réécriture jette non seulement du code, mais chaque bug que quelqu’un a déjà trouvé et corrigé, chaque cas limite étrange que le système actuel gère en silence parce qu’un vrai client l’a heurté il y a deux ans. Le remplaçant démarre propre et naïf, et réapprend tout cela à la dure, en production, avec votre nom dessus. Ce n’est pas un avis de niche. La version la plus claire de l’argument est le vieil essai de Joel Spolsky, Things You Should Never Do, écrit après avoir vu des entreprises incendier des produits qui marchaient en quête d’un nouveau départ. L’économie de tout cela n’a pas changé depuis.

La version honnête de la recommandation de réécriture est presque toujours plus étroite : une partie de ceci est vraiment pourrie, isolez et remplacez ce morceau, laissez le reste tranquille. Si votre auditeur ne sait pas vous dire quel module précis doit être remplacé et pourquoi le reste peut rester, il n’a pas fini l’audit. Nous avons écrit sur quand une réécriture est vraiment le bon choix, et le résumé tient en une ligne : moins souvent qu’on ne vous le dira, et jamais sur la foi d’une seule phrase spectaculaire.

Le test en quatre questions pour savoir si vous en avez besoin

Les audits coûtent de l’argent réel, et toutes les situations n’en réclament pas. Avant de commander quoi que ce soit, passez ces quatre questions. C’est la même forme que nous utilisons en interne quand un fondateur demande si ça en vaut la peine.

Première : suis-je sur le point de prendre une décision irréversible sur la base de ce code ? Virer un gros paiement, signer un contrat de construction, conclure une acquisition, miser une levée sur une démo. Si oui, auditez d’abord. Le coût de l’audit est un arrondi face au coût de la décision.

Deuxième : quelqu’un de mon côté sait-il lire ce code aujourd’hui ? Si la réponse est non, et qu’il devient porteur, l’audit vous achète des yeux que vous n’avez pas.

Troisième : le coût d’une erreur ici se mesure-t-il en clients ou seulement en temps ? Une fintech qui déplace de l’argent réel et un site de contenu n’ont pas la même réponse, et la première devrait auditer bien plus tôt que le second.

Quatrième : ai-je une personne indépendante capable de le faire, qui ne veut pas le travail qui suit ? Si vous ne l’avez pas, trouver cette personne est la vraie tâche, et elle vaut plus que de précipiter l’audit lui-même.

Si vous avez répondu oui aux trois premières et que vous avez un nom pour la quatrième, commandez l’audit. Si c’est non partout, ce que vous avez est une base de code normale avec une dette normale, et votre argent rapporte davantage à livrer du produit.

Un audit de code, bien mené, n’est pas un verdict rendu par quelqu’un de plus malin que vous. C’est une traduction. Il prend la seule partie de votre entreprise que vous ne savez pas lire et la transforme en une liste de décisions que vous savez parfaitement prendre. Les fondateurs qui se brûlent ne sont pas ceux qui ne savent pas coder. Ce sont ceux qui ont continué à signer sans jamais demander la traduction.

FAQ

Que signifie un audit de code ?
Un audit de code est une revue structurée d’une base logicielle menée par quelqu’un qui ne l’a pas écrite, évaluant la sécurité, la maintenabilité, l’exactitude et le risque opérationnel, et rapportant dans quel état elle est. Pour un propriétaire non technique, c’est un deuxième avis sur un code que vous avez payé, livré comme une liste de décisions de business plutôt qu’un verdict sur le code lui-même.

Combien de temps prend un audit de code ?
Pour un produit typique de stade précoce avec deux ou trois ans d’historique, un audit minutieux prend de quelques jours à deux semaines de temps d’ingénierie senior. Une revue uniquement de sécurité peut tenir en trois ou quatre jours. La variable, c’est la part du déploiement et de l’architecture qu’il faut reconstituer parce que personne ne l’a documentée.

Quels sont les quatre types d’audit ?
La réponse pleine de sigles liste des cadres de conformité, mais pour un fondateur les quatre angles utiles sont la sécurité (quelqu’un peut-il entrer), la maintenabilité (à quel point c’est difficile à modifier), l’exactitude (est-ce que ça marche et comment le savez-vous) et le risque opérationnel (que se passe-t-il quand ça casse et qui répare). Un vrai audit note les quatre, pas seulement la sécurité.

Qui mène en général les audits de code ?
Un ingénieur senior neutre ou un cabinet spécialisé qui n’écrit pas le code lui-même. La seule règle qui compte : jamais ceux qui l’ont construit, et idéalement personne qui profite de la reconstruction qu’il pourrait recommander. Demandez s’il est payé pareil si l’audit revient propre. La réponse vous dit si vous achetez un avis ou un argumentaire de vente.

Combien coûte un audit de code ?
Vous achetez des heures senior, pas un outil, donc le coût grimpe avec la taille et le désordre du système, de quelques milliers pour une revue bien cadrée à des dizaines de milliers pour un audit minutieux d’une base plus grande. Un « audit complet » à quelques centaines, c’est un scan automatique avec le nom d’une personne collé dessus, et ceux-là, vous les lancez vous-même.