Nos expertises / Diagnostic technique
Audit de code PHP : un rapport avec plan d'action détaillé
Vous ne savez pas ce que vaut le code de votre application, ou vous devez le prouver à quelqu'un ? En 2 à 5 jours, nous lisons votre projet avec les mêmes outils que nous utilisons sur les nôtres, et nous vous remettons un rapport classé par criticité.
Le socle vaut pour tout code PHP. Si votre application est sur Symfony, l'audit va plus loin : dépréciations, bundles, sécurité, calendrier de support.
Ça vous parle ?
Les situations qui justifient un audit
Vous ne savez pas ce que vaut le code que vous payez
Votre prestataire livre, le logiciel tourne, mais personne ne vous a jamais dit s'il est maintenable, à jour et sûr. Vous découvrirez la réponse le jour où quelqu'un d'autre devra y toucher.
Refonte totale ou évolution de l'existant ?
Tout réécrire ou continuer à faire évoluer ? Sans mesure objective, les avis divergent et la décision reste bloquée. Un rapport chiffré tranche là où les opinions tournent en rond.
Votre équipe manque de recul sur ses choix techniques
En interne ou chez votre prestataire, personne ne remet les pratiques en question. Un regard extérieur ne juge pas : il mesure, et il donne à l'équipe des arguments qu'elle n'avait pas.
Le déroulé
3 étapes, 2 à 5 jours
Un audit utile ne se résume pas à une liste de problèmes. Il produit un plan que vous pouvez exécuter dès le lendemain, avec nous ou sans nous.
Cadrage
Avant de lire une ligne de code, nous situons l'application : à quoi elle sert, qui l'utilise, ce qui motive l'audit aujourd'hui. C'est ce qui oriente l'analyse vers ce qui compte pour vous, plutôt que vers tout ce qui est techniquement imparfait.
- Entretien de découverte
- Accès au dépôt Git et aux dépendances
- Périmètre et priorités validés ensemble
Analyse
Les outils passent en premier, parce qu'ils sont exhaustifs et ne se discutent pas. La lecture humaine vient ensuite, sur ce qu'ils ne voient pas : responsabilités mal placées, règles métier dupliquées, décisions qui ne sont écrites nulle part.
- Huit axes, détaillés plus bas
- Outils publics, résultats rejouables
- Lecture du code par un développeur senior
Restitution
Le rapport classe chaque point par criticité, avec une recommandation concrète et un ordre de grandeur d'effort. Il est présenté à l'oral, pour que chaque recommandation soit comprise et discutée par toute l'équipe.
- Rapport classé par criticité
- Restitution orale
- Un plan qui vous appartient
Le format
Un audit, trois façons de s'en servir
Nous nous adaptons à votre contexte. Votre objectif : un logiciel en bonne santé, notre objectif : vous expliquer ce qui est améliorable et comment.
Le premier format suffit à décider. Les deux autres servent quand la décision est prise et qu'il faut la tenir dans le temps.
Audit seul : le one-shot
Vous attendez de nous une prestation unique. Vous repartez avec un plan d'action chiffré en effort, que vous exécutez avec votre équipe ou votre prestataire, sans nous. C'est le format d'une due diligence ou d'un arbitrage entre refonte et évolution.
Audit et contre-audit pour vérifier
Votre équipe corrige, nous repassons. Le second passage rejoue les mêmes outils sur le même périmètre et mesure ce qui a été traité, ce qui reste, et ce qui est apparu entre-temps. Vous obtenez un état daté, à remettre à un donneur d'ordre, un repreneur ou un investisseur qui l'exige.
Audit et accompagnement
Le rapport dit quoi faire, mais avez-vous les ressources et le temps disponible pour l'appliquer ?Selon ce que votre équipe peut absorber : prise en charge de certaines parties du plan, celles qu'elle n'a pas le temps ou l'expérience de traiter ; co-développement, en binôme et en revue de code, pour qu'elle sache refaire seule ; ou pilotage du plan d'action, que nous ordonnons et arbitrons pendant qu'elle le réalise. Nous saurons construire le format qui vous conviendra.
Ce que nous analysons
Un process rodé, depuis des années
Chaque axe est une section du rapport, avec le même plan : ce que nous avons regardé, ce que nous avons trouvé, ce que nous recommandons. Si votre application est sur Symfony, notre rapport sera encore plus détaillé.
Versions et dépendances
composer audit et osv-scanner sur l'inventaire des versions, confrontés à notre calendrier de support que nous tenons à jour et aux failles de sécurité référencées (CVE). C'est le point de départ : est-ce que nous sommes sur une bonne base ? Vous pouvez déjà vous faire une idée avec notre analyse de montée de version en ligne, à partir de vos versions de PHP et de Symfony.
Fin de support
PHP, framework, librairies : hors support, plus aucun correctif ne sortira, quelle que soit la faille.
Failles publiées (CVE)
Deux bases croisées (composer audit, osv-scanner), puis chaque alerte qualifiée : concernée ou pas, exploitable ou pas dans votre contexte.
Librairies abandonnées
Plus de mainteneur, plus de mise à jour : le point qui fige toutes les montées de version.
Dépendances superflues
Une librairie installée pour dix lignes qu'il valait mieux écrire : une surface de risque pour rien.
Conventions et maintenabilité
Ce qui permet à un développeur qui n'a jamais vu le projet d'y travailler dès le premier jour. Un code peut être juste et pourtant impossible à reprendre.
Style de code
Un standard (PSR) appliqué et vérifié par PHP CS Fixer, ou des habitudes qui changent d'un fichier à l'autre.
Documentation
Comment installer, lancer, tester et déployer, et les décisions d'architecture écrites quelque part.
Environnement de développement
Le projet se lance en une commande sur un poste neuf, ou il faut trois jours et un ancien de l'équipe.
Monitoring
Journaux exploitables, erreurs remontées, alertes : l'équipe apprend les incidents avant les utilisateurs, ou après.
Analyse statique
PHPStan et Psalm lisent tout le code sans l'exécuter et relèvent les erreurs de typage, les appels impossibles, le code mort. Le rapport donne le niveau atteint et ce qui sépare du niveau suivant.
PHPStan
Au niveau le plus strict que le projet supporte, avec le nombre d'erreurs à chaque niveau au-dessus.
Psalm
Un second regard, plus sévère sur les types et la nullité, qui trouve ce que PHPStan laisse passer.
Le niveau suivant
Combien d'erreurs, dans quels fichiers, et la part que Rector corrige automatiquement.
Couverture de tests
Ce qui est testé, ce qui ne l'est pas, et si les tests existants protègent réellement de quelque chose. Un projet sans test est le signe d'un manque de stabilité ou de vélocité.
Couverture mesurée
PHPUnit et la mesure de couverture sur la suite existante, exécutée telle quelle.
Zones critiques non couvertes
Règles métier, calculs, paiements : là où une régression coûte le plus cher.
Ce que les tests protègent
Un test qui ne vérifie rien fait monter la couverture de manière virtuelle sans aucun bénéfice.
Qualité du code
Les endroits où tout est lié, où une modification en casse dix autres parties souvent sans s'en rendre compte. Des copier-coller, des fonctionnalités qui évoluent vers des directions qui n'avaient pas été prévues à l'origine. Les pratiques de sécurité dans le code se lisent ici aussi, avec l'OWASP Top 10 comme grille de lecture.
Code dupliqué
La même règle écrite à plusieurs endroits, qui divergent avec le temps.
Complexité cyclomatique
Les fonctions aux dizaines de chemins possibles, impossibles à tester et à relire : celles à découper en premier.
Découplage
Contrôleurs qui portent le métier, requêtes dans les vues : ce qui empêche de modifier une partie sans toucher aux autres.
Bonnes pratiques
Injection de dépendances, séparation des couches, principes SOLID : appliqués, ou seulement connus.
Modèle de données
Le schéma de la base est ce qui se corrige le plus difficilement une fois les données en production : les mêmes défauts que dans le code, mais avec des années d'enregistrements à migrer derrière.
Données dupliquées
La même information stockée dans deux tables, mise à jour dans une seule : deux vérités qui divergent.
Colonnes hétérogènes
Plusieurs colonnes pour le même usage, un statut en texte libre ici et en entier là, des dates en chaîne.
Relations et index
Clés étrangères absentes, relations connues du code mais pas de la base, index manquants sur les colonnes filtrées.
Performance
Aucune mesure en production n'est nécessaire pour commencer : les pièges se lisent dans le code, et ce sont souvent de grands classiques. Quand un environnement est accessible, un profiling Blackfire confirme et chiffre ce que la lecture a repéré.
Pièges algorithmiques
Boucles imbriquées sur des collections entières, tris répétés, calculs refaits à chaque appel.
Requêtes SQL
Problème N+1, requêtes sans index, tables entières chargées pour en lire dix lignes.
Consommation mémoire
Milliers d'entités hydratées, fichiers lus d'un bloc, exports qui tombent au-delà d'une certaine taille.
Scan de sécurité
ZAP confronte l'application à ce qu'un attaquant en verrait de l'extérieur, sur un environnement d'intégration. Un scan en boîte noire, complémentaire de la lecture du code.
Scan passif et actif
Passif sans effet de bord, puis actif quand l'environnement le permet : injections, XSS, contrôle d'accès.
Configuration et en-têtes
Cookies, CSP, HSTS, informations qui fuitent dans les réponses : une heure de correction, longtemps protégé.
Alertes qualifiées
Chaque alerte relue : faux positif, réelle mais inexploitable, ou à corriger, et sous quel délai.
Si votre application est sur Symfony
Ce que l'audit ajoute sur un projet Symfony
Symfony est notre socle depuis nos premiers projets. Sur une application Symfony, l'audit ne se contente pas du PHP : il lit le framework, ses conventions, ses bundles et son calendrier. C'est aussi ce qui fait de cet audit la première étape naturelle d'une reprise de projet Symfony.
Analyse statique étendue
PHPStan et Psalm connaissent le conteneur de services, les entités et les requêtes : l'analyse voit les erreurs qu'un code Symfony cache derrière l'injection de dépendances et l'ORM.
- Extensions Symfony et Doctrine
- Services mal câblés
- Requêtes DQL invalides
Inventaire des dépréciations
Tout ce que la prochaine version majeure retirera, déjà signalé par le framework dans les journaux. C'est la mesure exacte de la distance qui vous sépare d'une montée de version.
- Journal des dépréciations
- Comptage par composant
- Ce que Rector corrige seul
État de chaque bundle
Maintenu, en sécurité seule, abandonné, à remplacer : un bundle d'administration ou d'authentification mort fige tout le reste. Le rapport dit lequel, et par quoi il se remplace.
- Sonata, EasyAdmin, API Platform
- Bundles abandonnés
- Remplaçant proposé
Configuration de sécurité
Pare-feux, contrôle d'accès, protection CSRF, gestion des secrets : ce que Symfony fournit et que le projet utilise, ou pas.
- security.yaml relu
- Rôles et voters
- Secrets hors du dépôt
Calendrier de support
Votre version de Symfony et de PHP confrontée aux dates officielles de fin de support, que nous tenons à jour et contrôlons automatiquement. Vous savez jusqu'à quand vous êtes couvert.
- Date de fin de support de vos versions
- Analyser votre socle en ligne
Chemin de montée de version
Ce que Rector automatise, ce qui reste à la main, et dans quel ordre passer les paliers : le rapport prépare la migration au lieu de la subir.
- Paliers dans l'ordre
- Part automatisable
- Migration Symfony
Au-delà du code
Parfois, les causes d'un logiciel instable ne sont pas dans le code
L'audit mesure un état du code. Quand les mêmes problèmes reviennent après chaque correction, la cause est ailleurs : dans la façon dont l'équipe travaille, dans ce qui n'est écrit nulle part, ou dans la distance entre ceux qui décident et ceux qui développent. Nous pouvons étendre l'audit à ces trois terrains.
Organisation d'équipe et gestion de projet
Comment les demandes arrivent, qui les priorise, comment elles sont livrées et recettées. Un code correct produit par une équipe sans méthode redevient fragile en quelques mois : l'audit regarde le flux, pas seulement le résultat.
- Rituels, tickets, planning
- Circuit d'une demande jusqu'en production
- Ce que nous avons fait chez Caprenov
Documentation métier et processus
Les règles que le logiciel applique sont-elles écrites quelque part, ou seulement dans le code et dans la tête de deux personnes ? Sans référentiel commun, chaque évolution se renégocie et chaque départ coûte une partie du métier.
- Glossaire et règles métier
- Processus tels qu'ils sont réellement pratiqués
- Écarts entre le logiciel et le terrain
Faire travailler ensemble métier et technique
Le métier ne comprend pas pourquoi une demande simple prend trois semaines, l'équipe technique ne comprend pas pourquoi la priorité change chaque lundi. Nous accompagnons les deux côtés à se lire, pour que les décisions se prennent avec les bonnes informations.
- Vocabulaire commun
- Ce que le métier doit savoir de la technique, et l'inverse
- Direction technique dans la durée
GLOSSAIRE
Le vocabulaire du rapport d'audit
Les termes que vous lirez dans le rapport et dans les échanges avec votre équipe. Chaque définition dit d'abord ce que ça change pour vous, puis comment ça se lit dans le code.
- Dette technique
- Tout ce qui a été fait vite pour livrer et qu'il faudra payer plus tard : chaque évolution coûte un peu plus cher que la précédente, jusqu'au jour où plus personne n'ose toucher au code. Le rapport la chiffre en effort de remise à niveau, poste par poste, pour que vous décidiez quoi rembourser et quoi assumer.
- Refactoring
- Réécrire une partie du code sans changer ce que le logiciel fait, pour le rendre plus simple à modifier. Rien de visible pour l'utilisateur, tout pour l'équipe. Un refactoring se fait sous protection de tests, sinon on ne sait pas si le comportement a été conservé.
- Couplage
- Le degré auquel les parties du code dépendent les unes des autres. Fort couplage : modifier la facturation casse l'export, et personne ne l'avait prévu. Dans du code PHP, il se lit dans les contrôleurs qui font tout, les classes qui instancient elles-mêmes leurs dépendances et les requêtes SQL dans les vues.
- Complexité cyclomatique
- Le nombre de chemins possibles dans une fonction : chaque if, boucle ou condition en ajoute un. Au-delà d'une dizaine, la fonction devient impossible à tester complètement et à relire sans se tromper. C'est une mesure objective, calculée par les outils, qui désigne les fonctions à découper en premier.
- Code spaghetti
- Du code où tout est emmêlé : les règles métier, l'accès aux données et l'affichage dans le même fichier, des fonctions de plusieurs centaines de lignes, des variables globales. Il fonctionne, mais chaque modification demande de tout relire. C'est le résultat typique d'années d'ajouts sans architecture.
- Code mort
- Des fonctions, des classes ou des fichiers que plus rien n'appelle, mais qui restent dans le dépôt. Ils trompent le lecteur, doivent être maintenus lors des montées de version et masquent le code réellement utile. L'analyse statique le repère, et sa suppression est l'un des gains les plus rapides d'un audit.
- PSR
- PHP Standards Recommendations : les conventions communes de la communauté PHP, du style d'écriture (PSR-12) au chargement des classes (PSR-4). Un projet qui les respecte peut être repris par n'importe quel développeur PHP. Un outil (PHP CS Fixer) les applique et les vérifie automatiquement.
- Principes SOLID
- Cinq règles de conception qui rendent un code modifiable sans effet de bord : une responsabilité par classe, ouvert à l'extension mais fermé à la modification, dépendre d'abstractions plutôt que d'implémentations... Beaucoup de développeurs les citent, l'audit regarde s'ils sont appliqués.
- Fin de support
- La date à partir de laquelle une version de PHP, de Symfony ou d'une librairie ne reçoit plus aucun correctif, même pour une faille de sécurité connue. Rester dessus n'est pas illégal, mais le risque est entièrement à votre charge. Nous tenons ce calendrier à jour et le rapport y situe chacune de vos versions.
- Dépréciation
- Une fonctionnalité que le framework signale comme condamnée : elle marche encore aujourd'hui, elle disparaîtra à la prochaine version majeure. Symfony les journalise en continu. Leur nombre mesure exactement le travail qui vous sépare d'une montée de version, et Rector en corrige une partie seul.
- Problème N+1
- Le piège de performance le plus courant sur un code PHP avec ORM : une requête pour lister 100 commandes, puis 100 requêtes pour charger le client de chacune. Invisible en développement avec dix lignes de données, catastrophique en production. Il se lit dans le code, avant toute mesure sur les serveurs.
- Régression
- Une fonctionnalité qui marchait et qui ne marche plus après une modification ailleurs. C'est le coût caché d'un code couplé et sans tests : chaque livraison peut casser ce qui était acquis. Les tests automatisés existent d'abord pour ça, et c'est ce que mesure l'axe couverture du rapport.
D'autres termes sont définis dans notre glossaire général.
Notre savoir-faire
L'expertise qui s'adapte à votre situation
Quel que soit votre point de départ, nous avons les compétences pour vous accompagner : créer de zéro, reprendre l'existant, valider une idée ou moderniser un outil qui montre ses limites.
Développement logiciel sur mesure
Vous avez un besoin métier que les logiciels du marché ne couvrent pas. On conçoit votre outil de zéro, depuis le cahier des charges jusqu'à la mise en production.
Reprise et refonte de logiciel
Votre logiciel existant freine votre transformation numérique : trop lent, trop rigide, impossible à faire évoluer. On reprend le code et on développe un outil spécifique à votre contexte.
TMA et maintenance évolutive
Votre logiciel est en production et doit le rester : corrections, évolutions, mises à jour de sécurité. Une équipe dédiée qui le connaît et le maintient dans la durée.
Prototype et MVP
Vous avez une idée de produit ou de SaaS à valider. On construit un premier outil fonctionnel pour tester vite et à moindre coût.
Hébergement et maintenance
Votre application tourne, mais qui s'assure qu'elle reste disponible, sécurisée et à jour ? On prend en charge le déploiement et le suivi.
Transformation Excel en logiciel
Votre Excel fonctionne mais commence à montrer ses limites. On le transforme en outil métier : automatisation des tâches répétitives, collaboration en temps réel, évolutivité sans contrainte.
Vous avez un doute ?
Même si nous sommes expert du digital, nous pensons qu'un échange par téléphone ou en visio est le moyen le plus simple de comprendre votre situation et de répondre à vos questions.
Contactez-nous directement pour savoir si nous pouvons vous aider à avancer.
Et après l'audit
Vous pouvez remettre le plan d'action à votre équipe ou à votre prestataire. Vous pouvez aussi nous confier la suite : le rapport devient alors l'état des lieux de la reprise, sans rien refaire.
« Nicolas est intervenu auprès de notre équipe de développement web et son intervention a été aussi utile que personnalisée.
Bien plus qu'un expert technique, il a donné des pistes d'évolution qui ont ouvert de nouvelles perspectives à l'équipe et donc à l'entreprise.
Nous avons donc décidé de continuer l'expérience par des interventions régulières. »
« Smartbooster a su nous accompagner en tant qu'AMO technique sur un marché de contrathèque pour un client public.
Le sourcing, la rédaction du cahier des charges, la réponse aux questions des candidats, l'analyse des offres techniques et sa présentation au client ont été professionnellement mené.
De plus Smartbooster est force de proposition et de très bons conseils. »
Pour aller plus loin
Approfondir votre réflexion
L'audit révèle des problèmes à traiter ? Nous pouvons prendre la suite : reprise du projet, remise en ordre, puis maintenance.
Analyse statique au niveau le plus strict, tests proportionnés aux enjeux, revue de code : les pratiques que l'audit mesure sont celles que nous appliquons.
Le rapport situe vos versions dans le calendrier de support. La page migration explique ce qui se passe quand une version arrive en fin de vie, et comment on monte.
Vous avez besoin d'un suivi technique régulier au-delà de l'audit ponctuel ? L'offre CTO externalisé prolonge l'analyse dans la durée.
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
En général 2 à 5 jours selon la taille du projet. Une application métier Symfony de taille moyenne s'audite en 3 jours. Le rapport est remis et présenté à l'oral à la fin de cette période.
Une section par axe d'analyse : versions et dépendances, conventions et maintenabilité, analyse statique, couverture de tests, qualité du code, modèle de données, performance, scan de sécurité. Puis un plan d'action où chaque point porte une priorité et un ordre de grandeur d'effort. Le rapport est le vôtre : vous pouvez le remettre à l'équipe de votre choix.
Le socle est le même, l'audit va plus loin. Sur Symfony, nous ajoutons les extensions Symfony et Doctrine de l'analyse statique, l'inventaire des dépréciations, l'état de chaque bundle (maintenu, abandonné, à remplacer), la configuration de sécurité, et la position de votre version dans le calendrier de support. C'est ce que décrit la seconde partie de cette page.
Oui. Le code source et le fichier de dépendances suffisent pour la quasi-totalité du rapport. L'accès aux serveurs n'est utile que pour la configuration d'infrastructure et les performances, et ce n'est pas un prérequis pour démarrer.
Blackfire, l'outil de profiling de référence sur Symfony : il montre fonction par fonction où le temps et la mémoire partent. Il est payant, et ce n'est pas un problème pour la durée d'un audit. Si votre équipe veut continuer à mesurer ensuite sans licence, Xdebug et KCachegrind font le même travail gratuitement, avec un peu plus de manipulations : le rapport indique comment les mettre en place.
Non. ZAP relève ce qu'un scanner automatique sait trouver : injections, XSS, en-têtes et cookies mal configurés, informations qui fuitent. Un test d'intrusion va plus loin, avec un humain qui enchaîne les failles et cherche ce que l'application permet de faire sans y être autorisé. C'est un métier à part, que nous ne prétendons pas exercer. Le scan corrige l'essentiel et prépare le terrain : si votre contexte exige un pentest, le rapport le dit et vous arrivez devant le prestataire spécialisé avec un code déjà propre.
Avant de changer de prestataire, pour ne pas hériter de problèmes cachés. Avant une évolution majeure, pour ne pas construire sur de mauvaises fondations. Quand le projet ralentit sans raison claire. Avant un rachat ou une levée de fonds, quand un tiers demande une due diligence technique. Ou simplement quand vous doutez des choix techniques de votre équipe et que vous voulez un regard extérieur.
Oui, mais ce n'est pas une obligation. L'audit est aussi la première étape de notre parcours de reprise : si vous nous confiez la suite, le plan d'action devient le plan de reprise. Si vous gardez votre équipe, le rapport lui sert de feuille de route.
Si l'objectif est de continuer sur une autre technologie, un prestataire qui la pratique au quotidien vous rendra un meilleur service, et nous vous le dirons. Si l'objectif est de reconstruire le logiciel, l'audit change de nature : il documente le fonctionnel, les données et les usages plutôt que le code. C'est le parcours de reprise d'un logiciel sur une technologie que nous ne maintenons pas.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.