Votre application tourne, et pourtant personne ne sait vous dire ce qu'elle vaut. Peut-on construire dessus encore trois ans, ou faut-il payer une réécriture ? Je lis le code, je mesure, et je vous réponds dans un document que vous gardez.
Un audit n'a de valeur que s'il peut conclure que tout va bien. C'est pourquoi je le facture seul, sans travaux derrière : je n'ai rien à gagner à vous annoncer que votre code est perdu, et vous n'avez pas à démêler l'avis technique de la proposition commerciale qui l'accompagne d'habitude.
Ce que vous recevez n'est pas une note sur vingt. C'est une liste de faits vérifiables, classée par ce qu'ils vous coûtent : les versions qui ne reçoivent plus de correctif de sécurité, les endroits que personne n'ose plus modifier, les tests qui manquent là où l'argent passe, et ce qui n'est pas grave malgré les apparences.
Un exemple vaut mieux que la promesse, alors en voici un : le bug qui déconnectait 71 % des inscrits d'une application, et que son développeur ne pouvait pas voir. Il n'est jamais remonté sous forme de ticket, et aucun test ne l'aurait trouvé.
Versions de PHP, de Symfony et de dépendances qui ne reçoivent plus de correctif, failles publiées sur les paquets installés, secrets commités dans le dépôt, données sensibles en clair. C'est la seule partie où je vous appelle avant d'avoir fini, parce qu'elle ne peut pas attendre la fin de l'audit.
Analyse statique sur tout le dépôt, couverture de tests, duplication, complexité des points chauds, requêtes qui s'écroulent avec le volume. Ce sont des chiffres relevés sur votre code, donc ils se re-mesurent après travaux : c'est ce qui rendra le progrès vérifiable, par vous, sans me croire sur parole.
Un rapport qui dit « le code est sale » ne sert à rien. Chaque constat porte ici son effet concret : le temps qu'une évolution simple prend aujourd'hui, ce qui casse à chaque livraison, la partie du logiciel qu'un nouveau développeur ne pourra pas toucher avant des semaines. Et l'ordre dans lequel régler tout ça.
Investir ou réécrire, monter de version ou tenir encore un an, garder l'équipe en place ou en changer, acheter cette application ou renoncer : la question se pose au premier échange et le rapport se conclut sur elle. Sans cette question, un document technique reste un document technique, et il finit dans un tiroir.
Boilerplate SaaS pour Symfony
Boilerplate commercial pour lancer un SaaS Symfony sans réinventer l'infrastructure : authentification (magic links, 2FA), facturation Stripe & Lemon Squeezy, multi-tenant avec équipes et rôles, dashboard admin (MRR, churn), chat IA en streaming. Suite de tests qui rejoue des cycles de facturation complets depuis des webhooks signés, PHPStan au niveau maximum sans aucune dérogation.
Vitrine & réservation bien-être
Refonte complète du site d'un praticien bien-être : présentation des soins, prise de rendez-vous en ligne et back-office d'administration. Symfony 8 + Tailwind.
Assistant juridique par IA
Plateforme privée d'aide à la constitution de dossiers juridiques, assistée par IA : journal de faits horodatés avec pièces, assistant répondant à partir du dossier (RAG), contrôles de confidentialité granulaires. Hébergement en France, données chiffrées.
Une synthèse d'une page pour la personne qui décide, puis le détail pour celle qui exécutera. Chaque constat porte trois choses : le fait, vérifiable dans le code à l'endroit indiqué ; ce qu'il vous coûte aujourd'hui ; le coût de la correction, en jours. Le tout classé par urgence réelle, sécurité d'abord. Il est rédigé pour qu'un autre développeur que moi puisse l'exécuter, et je vous le remets même si nous n'allons pas plus loin ensemble.
Deux à trois jours pour une application de taille courante, à 650 € par jour, annoncés avant de commencer et pas après. Un très gros dépôt se découpe : j'audite d'abord la partie qui porte votre décision, et vous voyez ce que ça donne avant d'engager la suite. Ce que je refuse de faire, c'est un audit à l'aveugle facturé au forfait : ni vous ni moi ne saurions ce qui est dedans.
En lecture, oui, et c'est la condition pour que le rapport vaille quelque chose : un audit sur un extrait choisi mesure surtout ce qu'on a voulu me montrer. Un accès en lecture au dépôt et à une base de données de recette suffit, sans toucher à la production. Je signe l'accord de confidentialité que vous voulez, et je travaille seul : votre code ne circule pas dans une équipe.
PHP est mon terrain depuis dix-huit ans : Symfony de la version 2 à la version 8, et beaucoup de PHP sans framework, qui reste très répandu dans les applications qu'on me donne à regarder. PostgreSQL et MySQL derrière, Apache et Debian pour l'hébergement. Sur un autre framework PHP, je vous le dis au premier échange : je sais lire n'importe quel code, mais un audit utile suppose de connaître les pièges de l'outil, et je ne les connais pas tous.
C'est le vrai risque d'un audit, et il se gère par la méthode plus que par les mots. Je parle aux développeurs en place avant d'écrire quoi que ce soit : ils savent déjà où sont les problèmes, et le plus souvent ils les ont signalés sans être entendus. Le rapport décrit du code, jamais des personnes, et il dit aussi ce qui est bien fait, ce qui n'est pas de la politesse : ce sont les parties sur lesquelles on s'appuiera. Un audit qui arrive comme un contrôle ne produit rien, parce que personne ne l'appliquera ensuite.
Oui, et c'est un des cas où un avis extérieur se rentabilise le plus vite. Ce qui compte alors n'est pas la propreté du code mais ce qui vous engage : dépendances non maintenues, licences incompatibles avec une revente, données personnelles mal cloisonnées, hébergement et noms de domaine détenus par quelqu'un d'autre, et le temps qu'il faudra à votre équipe pour tenir ce logiciel sans son auteur. Je peux travailler sous accord de confidentialité avec le vendeur, et le rapport vous est remis à vous seul.
Ce que vous décidez, y compris rien. Vos développeurs peuvent exécuter le plan, un autre prestataire aussi, et je peux le faire moi-même si vous me le demandez, au titre d'une reprise du projet existant : mais ça se décide après, sur un devis séparé, jamais dans le même mouvement. C'est la seule façon d'obtenir un avis qui ne dépende pas de la mission qu'il justifierait, et c'est aussi pour ça que je le facture seul.
Décrivez l'application en quelques lignes : ce qu'elle fait, depuis quand elle existe, qui l'a écrite, et la décision que vous avez à prendre. Je réponds sous 24 h, en vous disant franchement si un audit est utile dans votre cas, ou si la réponse tient en un échange.