Audit de code source
Mesurer la qualité et la maintenabilité de votre code.
- La dette enfin chiffrée
- Un ordre de priorité
- Les dépendances à risque
Audit
Personne ne peut répondre honnêtement sans avoir ouvert le code. Un audit applicatif remplace une intuition par un état des lieux et trois scénarios chiffrés.
Les problèmes
Un prestataire qui propose une refonte avant d'avoir lu le code ne vend pas une solution : il vend la seule chose qu'il sait faire.
« On nous annonce qu'il faut tout refaire, sans nous dire pourquoi. »
« L'application fonctionne, mais chaque évolution coûte de plus en plus cher. »
« Le développeur d'origine est parti, personne ne sait ce que ça vaut. »
« On hésite à investir encore dans un outil qui a peut-être fait son temps. »
Ce que vous recevez
Un audit ne vaut que par ce qu'il permet de décider. Les constats sont donc classés par gravité, avec l'effort de correction en face de chacun.
Ce qu'on examine
Extrait du rapport
Extrait de rapport donné à titre d'exemple : les constats affichés proviennent d'applications différentes, ils ne décrivent aucun client. Les comptes par gravité sont calculés sur la liste.
Ce qui est livré
Chaque point est inclus dans la prestation. Ce qui n'y figure pas vous sera annoncé dans le devis, jamais de mauvaise surprise.
Comment l'application est construite, ce qui dépend de quoi, et où se trouvent les points de fragilité. Un schéma qui tient sur une page.
Ce qu'il faudrait reprendre, en jours, et ce que coûte de ne rien faire. Une dette sans chiffre ne se décide pas.
Dépendances abandonnées, versions non soutenues, points uniques de défaillance, absence de sauvegarde. Classés par gravité.
Ce qui est utilisé, ce qui ne l'est plus. Sur une application ancienne, une part des écrans n'est plus ouverte par personne — et se supprime au lieu d'être refaite.
Entretenir, moderniser par étapes, reconstruire. Chacun avec son coût, son délai et ce qu'il fait gagner ou perdre.
Vingt à trente pages, avec une synthèse d'une page lisible par un dirigeant. Il vous appartient, y compris si vous travaillez ensuite avec un autre.

Comment ça se passe
Vous savez à tout moment où en est le projet et ce qu'on attend de vous.
Ce que vous voulez décider, et d'ici quand. Un audit qui ne sert pas une décision est un rapport qui finit dans un tiroir.
Accès au code et aux environnements, analyse des dépendances, mesures automatiques et lecture humaine des parties sensibles.
Ceux qui utilisent l'application, ceux qui la maintiennent. Le code dit ce qui existe, les utilisateurs disent ce qui gêne.
Le rapport, puis une heure pour le parcourir ensemble et répondre aux questions. Sans engagement de suite.
Ce qui fait la différence
Ce qu'un diagnostic écrit change, avant d'engager un budget.
Questions fréquentes
Des réponses claires aux questions les plus courantes, pour vous aider à y voir plus clair.
Oui, c'est la condition. Un audit fait depuis l'interface décrit des symptômes, pas des causes. L'accès se fait en lecture seule, sous accord de confidentialité, et les copies sont supprimées à la fin de la mission.
Non, et c'est précisément ce qui lui donne sa valeur. Il arrive que la conclusion soit « n'y touchez pas, ça tient » ou « votre prestataire actuel a bien travaillé ». Un audit qui conclut toujours à la refonte n'est pas un audit, c'est une proposition commerciale.
Une à trois semaines selon la taille de l'application. Le calendrier dépend surtout de votre disponibilité pour les entretiens et de la rapidité avec laquelle les accès sont fournis — c'est souvent ce qui prend le plus de temps.
Souvent associé à
Pour aller plus loin et maximiser l'impact de votre projet.
Mesurer la qualité et la maintenabilité de votre code.
Faire évoluer un logiciel ancien sans tout réécrire.
Corriger, mettre à jour et faire évoluer vos logiciels.
Audit applicatif
Un appel de découverte, sans engagement et sans présentation commerciale. On regarde votre situation, on vous dit ce qui est prioritaire — même si ce n'est pas chez nous.