La question arrive toujours dans le même ordre. On décide de refondre, on demande des devis, et quelqu’un demande : « est-ce qu’on ne devrait pas auditer l’existant d’abord ? » La réponse honnête n’est pas toujours oui. Voici comment trancher, et ce que contient réellement un audit quand il est justifié.
Ce qu’un audit avant refonte sert à décider
Un audit ne sert pas à produire un rapport. Il sert à répondre à trois questions dont dépend le budget de la refonte, et si vous connaissez déjà les trois réponses, l’audit est une dépense inutile.
Que garde-t-on ? Une refonte est rarement totale. Il y a presque toujours un module qui fonctionne, une base de données propre, un moteur de calcul métier qui a coûté des années à affiner. Savoir ce qui peut être repris change le chiffrage d’un facteur deux.
Qu’est-ce qui bloque ? Une dépendance qui n’existe plus, un composant dont plus personne ne détient les sources, un format de données propriétaire, une brique dont le fournisseur a disparu. Ces points ne se découvrent pas en réunion de cadrage : ils se découvrent en ouvrant le code, et il vaut mieux les découvrir avant le devis qu’au quatrième sprint.
Dans quel ordre ? Une refonte se déroule rarement d’un bloc. L’audit donne la séquence : ce qui doit partir en premier parce que tout le reste en dépend, ce qui peut attendre, ce qui peut être abandonné sans être remplacé.
Ce qui est réellement inspecté
Un audit technique sérieux couvre cinq plans. Aucun ne suffit seul.
Le code. Volume réel, couverture de tests, duplication, complexité cyclomatique des zones sensibles, dépendances obsolètes ou non maintenues, vulnérabilités connues. L’outillage donne les chiffres ; l’œil humain dit lesquels comptent. Une duplication massive dans un module stable qui ne sera jamais retouché est un faux problème.
L’architecture. Comment les composants se parlent, où sont les couplages qui empêchent de remplacer une brique sans toucher aux autres, quelles sont les frontières réelles — souvent différentes des frontières déclarées sur le schéma.
Les données. Qualité, cohérence, doublons, contraintes d’intégrité réellement appliquées. C’est le poste qui fait déraper le plus de refontes : migrer des données incohérentes coûte souvent plus cher que réécrire le code qui les manipule.
L’exploitation. Comment ça se déploie, combien de temps prend une mise en production, ce qui est monitoré, ce qui se passe quand ça tombe, qui est capable d’intervenir. Une application saine que personne ne sait redéployer est un risque de refonte, pas un actif.
La conformité. RGPD, hébergement, traçabilité des accès. Dans la santé, l’hébergement HDS et l’identification des professionnels s’ajoutent, et ce sont des contraintes d’architecture, pas des cases à cocher en fin de projet.
Combien de temps, combien ça coûte
Les ordres de grandeur que nous pratiquons, à titre indicatif :
| Périmètre | Durée | Budget indicatif |
|---|---|---|
| Audit ciblé — une application métier, le code et son architecture | 1 à 2 semaines | à partir de 8 000 € |
| Audit complet d’un SI — technique, sécurité, architecture, RGPD, dette | 4 à 8 semaines | 30 000 à 80 000 € |
| Due diligence technique avant acquisition ou levée | 2 à 3 semaines | selon périmètre, sous NDA |
Ces montants se comparent au budget de la refonte, pas à zéro. Un audit à 10 000 € qui évite de reprendre un module réutilisable, ou qui révèle en amont une migration de données à 60 000 €, s’amortit avant la première ligne de code. Le même audit sur une application de trois mois d’âge ne s’amortit jamais.
Quand l’audit ne sert à rien
Nous le disons en avant-vente, parce que c’est ce qui construit la confiance ensuite :
- L’application est récente et l’équipe qui l’a écrite est encore là. Elle connaît déjà les réponses aux trois questions. Un atelier de deux jours vaut mieux qu’un audit de deux semaines.
- La décision de tout jeter est déjà prise, pour une raison qui n’est pas technique. Changement de modèle métier, fin de contrat éditeur, obligation réglementaire : auditer un existant condamné ne change rien à la suite.
- Le périmètre est minuscule. En dessous d’une certaine taille, lire le code intégralement pendant le cadrage revient moins cher que le formaliser dans un rapport.
- L’audit sert à arbitrer un conflit interne. Un rapport ne remplace pas une décision. Il donne des faits ; il ne donne pas de mandat.
Choisir son auditeur
Un point de méthode qui compte plus que les certifications affichées : faites-vous auditer par des praticiens. Un auditeur qui sait ouvrir un IDE, faire tourner un scanner d’analyse statique et lire une trace de production produira un rapport actionnable. Un auditeur qui ne travaille qu’en entretiens produira une synthèse des opinions de vos équipes — utile, mais vous l’aviez déjà.
Deuxième point : exigez le chiffrage des remédiations. Un constat sans coût associé n’aide pas à décider. Ce qui vous intéresse, c’est « ce point-là représente douze jours et il est bloquant », pas « la dette technique est élevée ».
Troisième point, le plus inconfortable : demandez qui réalisera la refonte. Un auditeur qui espère emporter le chantier derrière n’a pas les mêmes incitations qu’un auditeur payé pour son seul avis. Les deux configurations sont défendables, à condition qu’elle soit dite.
Pour aller plus loin
Nous détaillons notre méthode et nos livrables sur la page audit de système d’information, avec les trois angles que nous traitons séparément : l’audit technique du code, l’audit d’architecture et de dette technique et l’audit sécurité et RGPD.
Si la décision de refondre est déjà prise, la page refonte de système d’information décrit la suite : trajectoire, découpage en lots et reprise de données.
Une question sur votre existant ? Parlez-nous de votre projet — le premier échange sert précisément à savoir si un audit est justifié dans votre cas.