En 2000, Joel Spolsky publiait 12 questions simples pour mesurer la maturité d'une équipe logicielle. Un quart de siècle plus tard, ce test reste l'un des outils de diagnostic les plus efficaces du secteur.
En août 2000, Joel Spolsky, cofondateur de Fog Creek Software et créateur de Trello, publiait sur son blog « Joel on Software » un article devenu une référence : The Joel Test. Le principe : 12 questions binaires (oui/non) qui permettent d'évaluer en deux minutes la qualité d'une équipe de développement. Score parfait : 12. Score acceptable : 11. En dessous de 10 : problème sérieux.
Ce qui rend ce test remarquable, c'est sa durabilité. Vingt-cinq ans plus tard, l'essentiel tient encore — même si certaines questions méritent une mise à jour au regard des pratiques modernes.
Les 12 questions
1. Utilisez-vous un système de gestion de versions ?
Aujourd'hui, la question serait : utilisez-vous Git avec une stratégie de branches ? Une équipe sans contrôle de version en 2024 est une curiosité. Mais la vraie question sous-jacente reste valide : vos pratiques de versioning sont-elles cohérentes et partagées par tous ?
2. Pouvez-vous faire un build en une seule étape ?
Un build complet — compilation, tests, packaging, déploiement — doit être déclenchable par une seule commande ou un seul clic. Si cette étape nécessite une checklist manuelle de dix actions, des erreurs se glisseront inévitablement. C'est le fondement de toute chaîne CI/CD sérieuse.
3. Faites-vous des builds quotidiens ?
Dans la logique de Spolsky, un build cassé arrête l'équipe. La règle : si un build est cassé en fin de journée, celui qui l'a cassé le répare avant de partir. Avec l'intégration continue moderne, cette question devient : vos pipelines CI tournent-ils sur chaque commit, et sont-ils pris au sérieux quand ils échouent ?
4. Avez-vous une base de données de bugs ?
Pas de bugs dans un tableur, pas de bugs dans les têtes, pas de bugs dans un fil Slack : une base de données dédiée, searchable, avec statut, priorité, et reproductibilité. Linear, Jira, GitHub Issues — l'outil importe peu. L'absence d'outil, si.
5. Corrigez-vous les bugs avant d'écrire du nouveau code ?
Le piège classique : accumuler une dette de bugs non résolus pour « livrer des fonctionnalités ». Chaque bug non corrigé est une charge cognitive permanente pour l'équipe, un risque de régression, et un signal envoyé aux utilisateurs. Les meilleures équipes traitent les bugs critiques immédiatement.
6. Avez-vous un planning à jour ?
Un planning ne sert pas à prédire l'avenir avec précision — c'est impossible. Il sert à forcer des conversations sur les priorités, à détecter les dépendances, à aligner les attentes avec les parties prenantes. Une équipe sans planning (ou avec un planning systématiquement ignoré) est une équipe qui subit.
7. Avez-vous des spécifications ?
Ce n'est pas une question de documentation exhaustive. C'est une question de réflexion. Écrire une spec — même courte — force à anticiper les cas limites, à trancher les ambiguïtés, et à aligner développeurs et product owners avant que le code soit écrit. Corriger une spec coûte zéro. Corriger du code en production coûte cher.
8. Les développeurs travaillent-ils dans le calme ?
Les interruptions sont l'ennemi de la concentration. Un développeur interrompu toutes les dix minutes ne peut pas entrer dans l'état de flow nécessaire au travail complexe. Cela concerne l'organisation de l'espace de travail, la culture des interruptions, et la gestion des réunions. Un agenda fragmenté en créneaux de 30 minutes est une machine à détruire la productivité.
9. Utilisez-vous les meilleurs outils disponibles ?
Les meilleurs développeurs sont ceux qui maîtrisent leurs outils. Un IDE lent, un laptop sous-dimensionné, des environnements de développement instables : ce sont des frictions quotidiennes qui s'accumulent. Lésiner sur l'outillage d'une équipe de développement est une fausse économie.
10. Avez-vous des testeurs dédiés ?
Spolsky est catégorique : si vous pensez que les développeurs peuvent tester leur propre code aussi bien qu'un testeur dédié, vous vous trompez. Le cerveau qui a écrit le code est mal placé pour trouver ses angles morts. Les tests automatisés ne remplacent pas les tests exploratoires humains — ils se complètent.
11. Les candidats écrivent-ils du code lors des entretiens ?
Un entretien sans exercice pratique ne révèle rien de la capacité à coder. Un CV impressionnant ne dit pas si la personne peut décomposer un problème, écrire du code propre sous contrainte, ou expliquer ses choix. Cette question reste l'une des plus importantes du test.
12. Faites-vous des tests d'utilisabilité dans les couloirs ?
L'idée est simple : prenez quelqu'un qui n'a pas travaillé sur le produit, montrez-lui une fonctionnalité pendant cinq minutes, et observez. Vous découvrirez des problèmes d'UX en quelques minutes que des mois de développement avaient occultés. Cinq testeurs non formés révèlent 85 % des problèmes d'utilisabilité selon les recherches de Nielsen.
Comment interpréter votre score
| Score | Interprétation |
|---|---|
| 12 / 12 | Équipe mature, pratiques solides |
| 11 / 12 | Très bon niveau, un point à adresser |
| 9 – 10 / 12 | Des lacunes significatives à corriger |
| < 9 / 12 | Problèmes structurels, dette organisationnelle élevée |
Le test ne mesure pas la qualité du code ni le talent individuel — il mesure les pratiques collectives qui permettent à une équipe de produire régulièrement des logiciels de qualité. Une équipe brillante avec de mauvaises pratiques produit en moyenne moins bien qu'une équipe ordinaire avec de bonnes pratiques.
Ce que le test ne couvre pas
Spolsky lui-même reconnaissait les limites de son test. En 2000, il n'avait pas prévu :
- Le déploiement continu (CD) et l'infrastructure as code
- Les pratiques de sécurité (SAST, revues de sécurité, gestion des dépendances)
- La culture du feedback : rétrospectives, one-on-ones, blameless post-mortems
- La dette technique et sa gestion explicite
- Le travail en équipe distribuée et ses défis spécifiques
Des tests plus récents comme le DORA metrics ou le Space framework complètent utilement cette grille.
Gotan et l'évaluation des équipes
Chez Gotan, nous utilisons le Test de Joël — enrichi de questions supplémentaires — comme point de départ lors de nos diagnostics d'équipes. Il permet d'ouvrir rapidement des conversations honnêtes sur les pratiques réelles versus les pratiques déclarées.
Ce qui ressort systématiquement : les équipes qui progressent le plus vite ne sont pas celles qui obtiennent 12/12 dès le départ. Ce sont celles qui identifient clairement leurs lacunes et s'attaquent méthodiquement aux deux ou trois points qui bloquent le plus leur efficacité collective.