Audit technique : les 12 points qu'on regarde vraiment — et on commence par les gens
Tout le monde croit qu'un audit technique commence par le code. C'est faux, et c'est même la meilleure façon de rater l'essentiel. Voici les douze points, dans l'ordre où ils comptent — en commençant par ceux dont personne ne parle.
Sommaire
Un audit sert à trancher, pas à décrire
La plupart des audits techniques échouent pour une raison simple : ils décrivent au lieu de trancher.
On vous remet quatre-vingts pages, une liste de « points d’attention » classés par couleur, et aucune recommandation qui engage celui qui l’écrit. Vous refermez le document, vous n’êtes pas plus avancé, et vous avez payé pour ça.
Un audit utile répond à une seule question : faut-il réparer, ou faut-il remplacer ?
Et pour y répondre, il ne commence pas par le code. C’est le contresens le plus répandu, et je vais commencer par lui.
Pourquoi on ne commence pas par le code
Imaginez qu’on vous demande d’auditer un restaurant qui ne tient plus ses délais.
Vous pourriez goûter les plats. Ce serait logique — c’est le produit fini, c’est ce que voit le client. Et ce serait une perte de temps.
Ce qu’il faut regarder d’abord, c’est si les cuisiniers savent cuisiner, et si leurs couteaux coupent. Puis qui décide quand la commande arrive en salle et que la cuisine est débordée. Le plat n’est que la conséquence.
Un logiciel, c’est pareil. Il n’est que la trace de ce que des gens ont su faire, avec les outils qu’on leur a donnés, dans une organisation qui les laissait décider ou non.
Un code médiocre écrit par une équipe compétente mal outillée se redresse en quelques mois. Un code correct maintenu par des gens qui ne le comprennent pas, dans une organisation où personne ne tranche, ne se redresse pas — quoi que vous fassiez au code.
C’est pour ça que les six premiers points de cet audit ne parlent pas de technique.
Famille 1 — Les gens
1. Savent-ils manipuler la matière ?
Première question, et elle est frontale : les personnes qui touchent ce logiciel savent-elles le faire ?
Cela ne se juge pas sur un diplôme ni sur un nombre d’années. Cela se juge en discutant une heure avec elles, sur leur propre code.
Ce qu’on cherche : est-ce qu’elles comprennent ce qu’elles maintiennent, ou est-ce qu’elles le modifient à tâtons, en priant ? Savent-elles expliquer pourquoi telle décision a été prise il y a trois ans, ou l’ont-elles héritée sans jamais l’interroger ?
Le signal le plus révélateur est une phrase : « on n’y touche pas, on ne sait pas ce que ça fait. »
Ce n’est pas un jugement sur les personnes. C’est souvent le symptôme d’un système qu’on leur a livré sans transmission — et cela se répare, à condition de le savoir.
2. Ont-ils de quoi travailler ?
On ne demande pas à un menuisier de bien travailler avec une scie qui ne coupe plus.
Et pourtant, on demande tous les jours à des développeurs de livrer vite avec un environnement de développement qui met vingt minutes à démarrer, sans outil de suivi correct, sans intégration continue, sans moyen simple de tester avant de livrer.
Ce qu’on regarde : combien de temps faut-il à un nouvel arrivant pour faire tourner le projet sur sa machine ? Si la réponse est « deux jours », vous venez d’apprendre l’essentiel. Combien de temps entre « le code est écrit » et « c’est en ligne » ? Si c’est une opération manuelle, redoutée, faite le vendredi par une seule personne, le problème n’est pas le code.
Un outillage médiocre produit du code médiocre, même avec de bons développeurs. L’inverse n’est pas vrai : un bon outillage ne sauve pas une équipe dépassée. Mais il coûte infiniment moins cher à corriger.
3. Combien de personnes comprennent ce système ?
Si la réponse est une, c’est le risque numéro un, avant tous les autres — avant la sécurité, avant la dette, avant tout.
Cette personne peut partir. Elle peut tomber malade. Elle peut simplement se lasser. Et le jour où cela arrive, ce n’est pas un problème technique que vous avez : c’est un arrêt d’activité.
Ce risque ne se corrige pas en écrivant du code. Il se corrige en documentant, en transmettant, et parfois en recrutant — c’est-à-dire en dépensant de l’argent sur quelque chose qui ne produit aucune fonctionnalité visible. C’est pour ça que personne ne le fait.
Famille 2 — L’organisation
Vous pouvez avoir un bon produit, des gens talentueux et de bons outils, et rester à l’arrêt. Il suffit que l’organisation empêche de décider.
4. Qui tranche ?
Question unique : quand deux personnes ne sont pas d’accord sur un choix technique, qui décide, et en combien de temps ?
Si la réponse est « on en discute », vous avez trouvé le frein.
C’est un rond-point où personne n’a la priorité : tout le monde s’arrête, tout le monde est poli, et plus rien n’avance. Chaque arbitrage remonte, attend un comité, redescend modifié, remonte à nouveau. Pendant ce temps, l’équipe compense en prenant des décisions par défaut — c’est-à-dire les pires.
C’est exactement la fonction qu’une direction technique est censée occuper, et son absence coûte plus cher que n’importe quelle dette.
5. Le circuit de décision fabrique-t-il de la lenteur ?
Un cycle long, séquentiel — tout spécifier, puis tout construire, puis tout valider — n’est pas illégitime en soi. Il l’est quand on l’applique à un produit qui doit évoluer.
Parce qu’il repose sur une hypothèse fausse : que l’on sait tout au départ. Or on ne sait jamais tout au départ. Alors chaque changement devient un avenant, chaque avenant une négociation, et l’équipe finit par éviter de proposer quoi que ce soit — ce qui est exactement le contraire de ce qu’on voulait.
Ce point est décisif si l’audit débouche sur une refonte. Refondre un système sans changer l’organisation qui l’a produit, c’est reconstruire la même maison avec les mêmes plans. Vous obtiendrez le même résultat, en plus récent, et vous serez au même point dans cinq ans.
6. Que se passe-t-il quand vous livrez ?
Ce n’est pas « y a-t-il des tests ? » — la réponse est souvent non, et ce n’est pas rédhibitoire.
La vraie question est celle du filet. Si chaque mise en production est une prise de risque que l’équipe redoute, si l’on ne livre que le mardi parce que « le vendredi c’est dangereux », alors il n’y a pas de filet.
Sans filet, une refonte progressive est impossible. On ne peut pas moderniser petit à petit ce qu’on n’ose pas toucher. C’est ce point, plus que la qualité du code, qui décide souvent entre « réparer » et « remplacer ».
Famille 3 — La matière
Maintenant, seulement, on regarde le logiciel.
7. Les dépendances et leurs versions
C’est rapide, et c’est brutal.
On liste ce dont le logiciel dépend, et on regarde les dates. Un composant dont la version installée n’est plus maintenue depuis trois ans, c’est un ascenseur que plus aucun ascensoriste n’accepte de réviser : il fonctionne, jusqu’au jour où il tombe — et ce jour-là, personne ne viendra.
Le signal le plus alarmant n’est pas une version ancienne, c’est un écart de plusieurs versions majeures avec la branche supportée. Parce que le coût d’une migration ne croît pas linéairement : il explose.
8. Ce qui tourne, où — et pouvez-vous partir ?
Quel serveur, quel hébergeur, quel compte, quelle région. Qui paie la facture, et sous quel nom.
Cela paraît trivial. Dans une TPE ou une PME, cet inventaire n’existe presque jamais, et sa seule production change la conversation.
Puis la question qui suit, et qui est la vraie : si vous devez changer de prestataire demain, que se passe-t-il ? Le code est-il sur un dépôt que vous détenez ? Les accès sont-ils à votre nom ?
Pouvez-vous changer de serrurier, ou est-il le seul à avoir le double ? C’est tout le sujet de notre article sur le prestataire injoignable.
9. La surface d’attaque, et les secrets
On ne fait pas un test d’intrusion. On mesure la surface d’attaque — c’est-à-dire l’ensemble des points par lesquels quelqu’un pourrait entrer.
L’image est littérale : chaque porte, chaque fenêtre, chaque soupirail d’une maison est un point d’entrée. Plus il y en a, plus il y a de choses à surveiller — et plus il y a de chances qu’on en ait oublié une ouverte.
Concrètement, on inventorie : les ports ouverts sur Internet, les panneaux d’administration accessibles, les formulaires publics, les API exposées, les intégrations tierces, les comptes qui existent encore alors que la personne est partie, les sous-domaines oubliés qui pointent encore vers un vieux serveur.
Chaque service qu’on ajoute agrandit cette surface. C’est l’arbitrage permanent d’une architecture : chaque commodité nouvelle est une porte de plus.
Et l’immense majorité des incidents qui touchent une PME n’exploite pas une faille sophistiquée — elle exploite une porte laissée ouverte.
Les secrets relèvent du même point. Mots de passe, clés d’API, jetons : on cherche s’ils sont dans le code, dans l’historique du dépôt, dans un fichier de configuration versionné.
C’est le constat qui remonte le plus souvent, et de très loin. Attention au piège : un secret déposé une fois dans l’historique y reste, même après avoir été retiré du fichier. C’est la clé sous le paillasson : vous avez beau la reprendre, la photo du paillasson avec la clé est restée dans l’album. Il ne suffit pas de l’enlever — il faut changer la serrure.
10. Les sauvegardes — et la preuve qu’elles existent
Voici le point le plus mal compris de tout l’audit, et celui qui provoque les pires réveils.
Tout le monde a des sauvegardes. Presque personne n’a la preuve qu’elles fonctionnent.
Prenez un vieux magnétophone à bobines. La bobine arrive au bout. Les têtes continuent de tourner, la petite lumière rouge reste allumée, l’aiguille bouge encore — tout indique que ça enregistre. Mais plus rien ne s’écrit.
Un système de sauvegarde fait exactement ça. Le disque est plein, l’espace distant a été révoqué, le certificat a expiré, le script échoue silencieusement depuis huit mois — et le tableau de bord reste vert, parce qu’il rapporte que la tâche s’est lancée, pas qu’elle a écrit quelque chose de restaurable.
Il n’y a qu’un seul moyen de savoir : rejouer la bande. Restaurer, réellement, sur un environnement séparé, et vérifier que les données sont là et qu’elles sont exploitables.
Une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde. C’est une croyance.
C’est pour cela qu’on ne demande jamais « avez-vous des sauvegardes ? » — tout le monde répond oui. On demande : « quand avez-vous restauré pour la dernière fois, et combien de temps ça a pris ? » Le silence qui suit est souvent la réponse la plus instructive de l’audit.
11. La dette, mesurée — et ce que coûte l’infrastructure
« Il y a de la dette » n’est pas un constat, c’est une évidence. La question utile est : combien elle vous coûte par mois.
Comme un emprunt, la dette technique n’est pas une faute : on l’a contractée pour aller plus vite, souvent à raison. Ce qui coûte, ce sont les intérêts — le temps supplémentaire que chaque évolution demande désormais.
On la mesure à ce qui s’observe : le temps qu’il faut pour livrer une modification simple, aujourd’hui comparé à il y a deux ans ; la part de l’effort qui part en correctifs plutôt qu’en nouveautés ; le nombre d’endroits à toucher pour un changement anodin.
Une dette qui ne ralentit rien peut attendre. Une dette qui triple le coût de chaque évolution doit être remboursée — et cela se chiffre.
Au passage, on regarde aussi ce qui est payé chaque mois et qui ne sert plus : les serveurs surdimensionnés, les services souscrits puis oubliés, les environnements de test allumés depuis deux ans. Ce point ne relève pas de la technique mais de la trésorerie — et c’est souvent lui qui finance le reste de l’audit.
12. La conformité : RGPD, NIS2, licences, propriété
Dernier point, et il est devenu le plus lourd de conséquences.
Le RGPD s’applique dès que vous traitez des données personnelles — c’est-à-dire à peu près tout le monde. Ce qu’on vérifie n’est pas une case à cocher : quelles données sont réellement collectées (souvent bien plus que ce que le dirigeant croit), pourquoi, combien de temps elles sont conservées, qui y a accès, et où elles partent. Un formulaire qui envoie des données à un service tiers hors UE sans que personne ne l’ait décidé, c’est courant. Notre article protection des données personnelles : par où commencer donne le point de départ.
NIS2 est le sujet que la plupart des dirigeants découvrent trop tard. La directive élargit considérablement le périmètre des entreprises soumises à des obligations de cybersécurité : elle vise des secteurs listés — énergie, transport, santé, eau, numérique, agroalimentaire, fabrication, services postaux, entre autres — au-dessus de certains seuils de taille. Beaucoup de PME qui se croyaient hors sujet y entrent.
La première chose qu’un audit doit faire, ce n’est pas de vous mettre en conformité : c’est de vous dire si vous êtes concerné. C’est une question de quelques heures, et l’ignorance ne protège de rien.
Les licences. Votre logiciel s’appuie sur des dizaines de bibliothèques écrites par d’autres, chacune sous une licence. Certaines sont incompatibles avec un usage commercial fermé. Personne ne fait jamais cet inventaire — jusqu’à ce qu’un investisseur le demande.
La propriété du code, enfin. En droit français, la cession des droits n’est jamais automatique : avoir payé ne suffit pas. C’est le point qui tue les opérations, et nous lui avons consacré un article : propriété du code source.
Ce que l’audit doit produire
| Livrable | À quoi ça sert |
|---|---|
| Un inventaire complet | Vous savez enfin ce que vous possédez, et où |
| Une hiérarchie des risques | Ce qui menace l’exploitation, ce qui coûte cher, ce qui peut attendre |
| Une recommandation tranchée | Réparer ou remplacer — écrit noir sur blanc, avec les raisons |
| Un chiffrage | Ce que coûte chaque option, sur quelle durée |
| Une feuille de route | Dans quel ordre, avec quels jalons |
La ligne en gras est la seule qui compte vraiment. Les autres l’étayent.
Le résultat auquel personne ne s’attend
L’audit peut conclure qu’il ne faut rien faire.
Nous l’avons écrit plusieurs fois : un système jugé « catastrophique » par son propriétaire était en réalité daté mais sain, correctement sauvegardé — et il valait bien mieux investir l’argent ailleurs. Le dirigeant était déçu ; il s’était préparé à une refonte. Il a économisé une année et un budget.
Méfiez-vous d’un auditeur qui recommande systématiquement une refonte. C’est ce qui rapporte le plus à celui qui la vend.
Et méfiez-vous encore plus d’un auditeur qui n’a parlé qu’au code. Le code ne ment jamais, mais il ne dit pas tout — il ne vous dira pas qui n’ose plus le toucher, ni pourquoi personne ne tranche.
Un audit technique commence toujours par une conversation, pas par un accès au dépôt. Si vous ne savez pas encore si votre sujet en relève, c’est justement le moment d’en parler : prenons contact.
Retrouvez nos articles en priorité dans vos résultats Google en nous ajoutant à vos sources préférées.
Ajouter aux sources préférées
