Audit applicatif
Évaluer ce que vaut votre application et ce qu'elle coûte.
- Une décision appuyée
- Le coût du statu quo
- Un document opposable
Audit
Un code qui se dégrade ne tombe pas en panne : il ralentit tout. Le devis augmente, les délais s'allongent, et personne ne sait dire pourquoi.
Les problèmes
La qualité du code ne se voit pas depuis l'extérieur. Elle se lit dans le temps qu'il faut pour livrer la moindre modification.
« Chaque nouveau développeur met des mois à être autonome. »
« On a peur de toucher à ce fichier, il fait quatre mille lignes. »
« Le même calcul est écrit à cinq endroits différents. »
« On nous parle de dette technique sans jamais la chiffrer. »
Ce que vous recevez
Une dette technique sans chiffre ne se décide pas. Chaque constat porte donc l'effort de reprise, et le classement suit ce que cela vous coûte de ne rien faire.
Ce qu'on mesure
Extrait du rapport
Extrait de rapport donné à titre d'exemple : les constats affichés proviennent de bases de code différentes, ils ne décrivent aucun client.
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.
Complexité, duplication, taille des fichiers, couverture de tests. Obtenues avec des outils reconnus, comparées à des seuils publics et non à une opinion.
Les parties sensibles lues à la main : gestion des erreurs, sécurité, règles métier. Aucun outil ne détecte une règle de calcul fausse.
Le même traitement écrit plusieurs fois est la première cause de bugs qui reviennent : on corrige une copie, on oublie les autres.
Bibliothèques abandonnées, versions vulnérables connues, licences incompatibles avec un usage commercial. Trois risques qu'on découvre toujours trop tard.
Ce qu'il faut corriger, dans quel ordre, avec le coût en jours et le gain attendu. Tout n'est pas à reprendre — l'essentiel est de savoir quoi.
Une synthèse d'une page pour décider, le détail derrière pour les développeurs. Les deux publics ne lisent pas le même document.

Comment ça se passe
Vous savez à tout moment où en est le projet et ce qu'on attend de vous.
Quels dépôts, quelles branches, et quelle décision l'audit doit éclairer. On exclut ce qui n'est plus en service.
Passage des outils d'analyse statique, relevé des mesures, détection des dépendances à risque.
Les zones les plus complexes, les plus modifiées et les plus sensibles, lues à la main.
Rapport remis, puis une séance avec vos développeurs : ce sont eux qui appliqueront le plan.
Ce qui fait la différence
Ce qu'une mesure objective change, dans une discussion technique.
Questions fréquentes
Des réponses claires aux questions les plus courantes, pour vous aider à y voir plus clair.
Non. Beaucoup de choix critiquables s'expliquent par un délai court ou un budget contraint à un moment donné — et nous le disons quand c'est le cas. L'audit décrit l'état du code et son coût futur, pas la compétence de qui l'a écrit.
Il donne les mesures, et elles sont utiles. Mais il ne voit ni une règle métier fausse, ni une faille logique, ni le fait qu'un fichier énorme soit en réalité stable et jamais modifié. Les mesures seules classent mal les priorités.
Trois usages courants : arbitrer entre entretien et refonte, cadrer le travail de vos propres développeurs, ou consulter d'autres prestataires sur une base commune. Le rapport vous appartient et reste exploitable sans nous.
Souvent associé à
Pour aller plus loin et maximiser l'impact de votre projet.
Évaluer ce que vaut votre application et ce qu'elle coûte.
Détecter les régressions avant vos utilisateurs.
Faire évoluer un logiciel ancien sans tout réécrire.
Audit de code source
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.