Combien de temps faut-il pour savoir si un outil d’analyse de code vaut le coût de son abonnement ? Sur un projet d’agence gérant une dizaine d’extensions WordPress maison, on a branché SonarQube, Scrutinizer CI et Codacy simultanément sur le même dépôt Git pendant six semaines, avant de trancher. Voici ce que ça a donné, en dehors de tout discours commercial.
Le contexte compte : un dépôt de taille moyenne, environ 40 000 lignes de PHP réparties sur cinq extensions, plus quelques milliers de lignes de JavaScript pour des blocs Gutenberg personnalisés. L’objectif était de bloquer les régressions de qualité sur les pull requests, pas de refaire l’historique du code existant.
SonarQube : le plus complet, le plus lourd à porter
SonarQube détecte le plus large éventail de problèmes : failles de sécurité potentielles, duplication de code, complexité cyclomatique excessive, et une notion de « dette technique » chiffrée en temps estimé de correction. Le plugin communautaire pour PHP couvre correctement WordPress, à condition de configurer soi-même les règles pour ne pas signaler comme faute des patterns légitimes du cœur, comme l’usage massif de fonctions globales.
La version Community s’auto-héberge gratuitement, mais demande un serveur dédié avec une base PostgreSQL, ce qui représente un coût d’exploitation réel pour une petite équipe. La version Cloud supprime cette contrainte, au prix d’un abonnement par ligne de code analysée qui grimpe vite sur un dépôt de plusieurs dizaines de milliers de lignes.
Le Quality Gate, ce mécanisme qui bloque une pull request tant que les métriques définies ne sont pas respectées, est le vrai atout de l’outil : on peut exiger par exemple zéro nouvelle vulnérabilité et une couverture de tests minimale sur le code modifié, sans toucher au code legacy non couvert.
Codacy : l’intégration la plus rapide, la facture la plus salée
Codacy se distingue par sa simplicité de mise en route : connexion au dépôt GitHub, sélection des standards PHP et ESLint souhaités, et les premières analyses tournent en moins de dix minutes, sans configuration serveur. L’interface classe les problèmes par catégorie (sécurité, complexité, style, documentation) et affiche un badge de couverture directement dans les pull requests.
Le revers se voit à la fin du mois : la tarification par contributeur actif rend l’outil coûteux dès que l’équipe dépasse trois ou quatre développeurs réguliers, sans réduction notable pour un usage sur des dépôts privés d’agence gérant plusieurs projets clients séparés. Pour une petite structure qui facture ses développements au client, ce coût doit être explicitement intégré au devis, ce qu’on a parfois oublié de faire lors des premiers mois d’essai.
Scrutinizer CI : discret mais efficace sur un budget serré
Moins connu, Scrutinizer CI cible spécifiquement PHP et propose une analyse statique fine, avec des suggestions de correction directement sous forme de diff proposé en commentaire de pull request. Son plan gratuit couvre les dépôts open source, et son offre payante pour dépôts privés reste sensiblement moins chère que Codacy à effectif équivalent.
Sa faiblesse : le support JavaScript est plus limité, et l’interface, moins soignée, demande un peu plus de tâtonnement pour configurer des règles personnalisées adaptées aux conventions WordPress (globals autorisés, préfixage des fonctions, etc.).
Comparatif synthétique
| Critère | SonarQube (Cloud) | Codacy | Scrutinizer CI |
|---|---|---|---|
| Mise en route | Modérée (config Quality Gate) | Très rapide | Rapide |
| Couverture PHP | Très complète | Bonne | Très bonne |
| Couverture JS/TS | Bonne | Bonne | Limitée |
| Auto-hébergement | Possible (Community) | Non | Non |
| Coût pour 5 devs, dépôt privé | Élevé | Élevé | Modéré |
| Suggestions de correction en PR | Limitées | Oui | Oui, en diff |
Le vrai coût caché : le temps de calibrage des règles
Sur les trois outils, la première semaine s’est soldée par une avalanche d’alertes, la plupart sans intérêt pour du code WordPress : fonctions globales signalées comme mauvaise pratique, complexité jugée excessive sur des switch de gestion de hooks pourtant lisibles, avertissements sur des superglobales $_POST déjà correctement filtrées. Aucun outil n’a de profil WordPress prêt à l’emploi vraiment satisfaisant : il faut systématiquement désactiver ou pondérer une partie des règles par défaut, sous peine de noyer les vraies alertes dans le bruit.
- Compter au moins une demi-journée de calibrage initial par outil avant de l’activer en bloquant sur les pull requests
- Exclure d’emblée les dossiers
vendor,node_moduleset les fichiers minifiés livrés par des bibliothèques tierces - Activer le blocage progressif : d’abord en mode rapport seul, puis en mode bloquant une fois les faux positifs éliminés
Un outil d’analyse continue mal calibré est pire que l’absence d’outil : l’équipe apprend à ignorer les alertes rouges, et le jour où une vraie faille de sécurité est signalée, personne n’y prête attention.
Notre verdict
Pour une petite équipe ou une agence qui gère plusieurs dépôts privés avec un budget contraint, Scrutinizer CI offre le meilleur rapport entre pertinence des alertes PHP et coût. Pour une structure qui a déjà investi dans une gouvernance qualité formalisée, avec des Quality Gates partagés entre plusieurs équipes et des exigences de conformité, SonarQube Community auto-hébergé reste le choix le plus solide, à condition d’accepter la charge d’exploitation d’un serveur supplémentaire. Codacy convainc surtout les équipes qui veulent une mise en route immédiate sans administration technique, et qui peuvent absorber son coût par contributeur sans discussion. Il n’existe pas de vainqueur universel : le bon choix dépend d’abord de la taille de l’équipe et de qui, dans la structure, porte le coût de l’outil.
