Avant de rejoindre une Big Tech, j’ai été Tech Lead pendant trois ans et demi sur une application Angular qui coûtait plus d’un million d’euros par an au client. Avant de partir, j’ai pris une journée complète pour relire une par une les quelque 200 tâches techniques que nous avions créées, déployées et supervisées dans Jira : refactorings, montées de version, conventions d’équipe, pipelines CI, workshops.
Pour chacune, une question simple : qu’est-ce qui a vraiment aidé le projet, qu’est-ce qui a moins marché, qu’est-ce qu’on n’aurait jamais dû faire ?
Le constat n’était pas celui que j’attendais. Ce qui nous avait le plus aidés, ce n’étaient pas les tâches « sexy » comme la dernière librairie à la mode ou le grand chantier d’architecture. C’était l’ordre dans lequel nous avions exécuté les tâches. Chaque fois que nous avions sauté une étape pour aller directement vers ce qui nous faisait plaisir, ça avait échoué.
C’est comme ça qu’est née la Pyramide du Code Senior : un framework en six niveaux qui donne l’ordre dans lequel attaquer la dette technique d’un projet. Je l’utilise encore quotidiennement dans une Big Tech qui fait tourner plus de 200 applications Angular en production. Cet article prolonge la vidéo ci-dessous.
Niveau 1 : L’iceberg, tes dépendances
Quand j’audite une codebase, la première chose que je regarde n’est pas le code. C’est le package.json.
La raison est mathématique : dans le bundle qui tourne en production, l’essentiel du code ne vient pas de ton équipe. Sur un million de lignes livrées, il est courant que 100 000 aient été écrites par l’équipe et 900 000 par les librairies utilisées. C’est le problème de l’iceberg : 90 % du code de ton projet est invisible dans tes revues de code.
Peu importe ton niveau en architecture si tes fondations reposent sur des librairies dépréciées. Ce qui tue un projet à long terme, c’est rarement un mauvais composant. Le vrai risque est de rester bloqué dans un écosystème du passé qui ne peut plus évoluer.
Action de 5 minutes : lance npm audit et npm outdated. Le but n’est pas un score parfait sur chaque dépendance, mais d’identifier ce qui est bloquant ou dangereux : une version majeure d’Angular en retard de plusieurs années, des dépendances CommonJS à migrer vers les modules ES, des failles de sécurité connues.
Niveau 2 : La feuille A4, la standardisation
Vois ton projet comme des dizaines de milliers de feuilles A4 : chaque composant, chaque service, chaque utilitaire est une page. Pour que le livre soit lisible, chaque page doit être écrite dans la même langue, indentée de la même manière, cohérente avec les autres.
Les outils existent depuis longtemps : linter, configuration TypeScript, formateur comme Prettier. Le vrai levier est ailleurs : repère dans tes dernières revues de code les débats « X versus Y », ces sujets où l’équipe a l’impression qu’il existe deux manières de faire. Tranchez en équipe, puis transformez la décision en règle de linter.
Action de 5 minutes : déploie une première règle simple, par exemple interdire les imports, les variables ou les paramètres de fonction inutilisés. Chaque règle ajoutée enlève du bruit des revues de code et de la charge mentale de l’équipe.
Niveau 3 : Les spaghettis, l’architecture
Grâce aux niveaux 1 et 2, chaque brique est bien construite. Le problème, c’est qu’elles sont reliées n’importe comment : dépendances circulaires, composants de bas niveau qui importent des composants de haut niveau. Résultat connu : toucher un bout du code casse tout le reste.
Les principes SOLID, le Domain-Driven Design et la Clean Architecture aident à structurer. Mais quand toi ou ton agent IA opérez dans un coin du code, il est impossible de garder la big picture en permanence et l’architecture se désagrège toujours un peu. La réponse : un « linter d’architecture » comme Sheriff ou Nx, qui interdit mécaniquement les importations dans le mauvais sens.
Action de 5 minutes : identifie l’« usine à bugs » de ton projet. Il y a toujours un composant ou un service trop gros qui provoque deux ou trois bugs dès qu’on le touche. Tu ne le refactoreras pas en 5 minutes. En revanche, tu peux décider aujourd’hui de protéger le code futur avec une règle d’architecture.
Newsletter Codeur Senior
Passez de l'exécution au produit.
Recevez les prochaines analyses pour sortir de la régie, piloter des agents sous vos standards et construire une preuve qu'une boîte produit peut évaluer.
Niveau 4 : L’humain, la dette d’ignorance
Il existe trois dettes pour un développeur : la dette financière, la dette technique, et la dette d’ignorance. La troisième se paie tous les jours sans qu’on la voie : personne dans ton équipe n’opère avec le même modèle mental sur les technologies, le produit et les processus.
L’exemple classique : John livre sa feature un vendredi à 16 h et découvre qu’un code freeze interdit les livraisons après 14 h le vendredi. Le pire réflexe est de lui répondre « tout le monde le sait ». Les gens arrêtent alors de poser des questions, et chacun garde son modèle mental désynchronisé.
Action concrète : construis une matrice de compétences. Liste en lignes ce qu’il faut savoir pour opérer sur le projet (technologies, produit, processus), mets les membres de l’équipe en colonnes, et laisse chacun s’auto-noter de 1 à 5. Le but n’est pas que tout le monde soit à 5. Il faut surtout éviter qu’une seule personne devienne un goulot d’étranglement et que quelqu’un reste bloqué en bas.
Niveau 5 : La vélocité, livrer plus vite
Le code est propre et l’équipe est synchronisée. Pourtant, vous livrez trop lentement. Quand le business a besoin d’aller plus vite, pense production de burger : si une action prend trois clics, peut-elle en prendre un seul ? Si une validation exige quatre personnes, deux suffisent-elles ?
Regarde les workflows récurrents de ton équipe : intégration Git, traductions, déploiements en production. Standardise, élimine, accélère.
Niveau 6 : Le maximum local, ton équipe n’est pas l’entreprise
Le niveau le plus dur, parce qu’il est organisationnel : les priorités de ton équipe ne sont pas exactement celles de l’entreprise. Pendant un Black Friday, j’ai dû arbitrer entre le bug urgent de mon équipe et un hotfix de production demandé par une équipe externe : au niveau local, mon bug passait d’abord ; au niveau global, le hotfix comptait plus.
Action concrète : identifie un coût invisible que ton équipe fait payer aux autres. Exemple : des conventions d’équipe orales que les contributeurs externes découvrent en revue de code. Une règle de linter avec un message de suggestion fait gagner du temps à tout le monde.
L’ordre compte autant que la pyramide
Une architecture brillante posée sur des dépendances obsolètes s’effondre à la première migration. Aider les autres équipes (niveau 6) alors qu’on livre lentement (niveau 5) est un contresens. Si tu as le temps devant toi, attaque par le bas : niveau 1, puis 2, jusqu’au 6. Le reste est un arbitrage en fonction de l’urgence du moment.
Si tu veux recevoir mes prochaines analyses sur le passage de l’exécution au produit, rejoins la newsletter.