Posture senior : guide architecture .NET

En clair

Être senior, ce n'est pas seulement connaître plus de technique. C'est savoir choisir entre plusieurs solutions et expliquer pourquoi, faire grandir les autres, voir venir les problèmes avant qu'ils arrivent, et oser dire « non, pas comme ça » avec des arguments.

De junior à senior Junior

Dimension	Junior	Confirmé	Senior
Périmètre	Une tâche bien définie	Une fonctionnalité de bout en bout	Un système, plusieurs équipes
Problèmes	Résout avec aide	Résout seul	Anticipe et évite
Code	Fonctionne	Fonctionne, testé, lisible	Simple à changer dans deux ans
Choix techniques	Applique	Propose	Arbitre, documente, assume
Production	Découvre	Diagnostique	Conçoit pour l'exploitation (logs, rollback, alertes)
Équipe	Apprend	Aide ses voisins	Fait monter le niveau de tous
Métier	Exécute la demande	Comprend le besoin	Questionne le besoin, propose plus simple

Arbitrer et expliquer Senior

Une décision technique se présente toujours avec au moins deux options, leurs coûts et leurs risques, et une recommandation. « On doit faire des microservices » n'est pas un argument ; « séparer la facturation permet de la déployer sans geler le catalogue, au prix d'un message asynchrone et d'une base de plus » en est un.

Réversible ?

Une décision facile à défaire se prend vite. Une décision coûteuse à défaire (base, langage, découpage en services) mérite une étude et un ADR.

Coût total

Développement, mais aussi exploitation, formation, licences, astreinte et migration future.

Qui en paie le prix ?

Une solution élégante pour le dev peut coûter cher à l'exploitation ou au support.

docs/adr/0007-separer-la-facturation.md

# 7. Séparer la facturation dans un service dédié

Statut : accepté — 2026-10-15
Décideurs : équipe Commandes, équipe Finance

## Contexte
La facturation change chaque mois (règles fiscales) et bloque les déploiements du catalogue.

## Options
1. Rester dans le monolithe, module isolé + tests d'architecture
2. Service séparé sur Cloud Run, communication par Pub/Sub

## Décision
Option 2. Déploiements indépendants, propriétaire unique (équipe Finance).

## Conséquences
+ Mise en production de la facturation sans gel du catalogue
− Cohérence éventuelle : une facture peut apparaître quelques secondes après la commande
− Outbox, idempotence et supervision d'un service de plus

Revue de code Confirmé

Priorité	Ce qu'on regarde
1	Exactitude : le code fait-il ce qui est demandé, y compris dans les cas limites (null, vide, concurrence, annulation) ?
2	Conception : est-ce au bon endroit dans l'architecture ? Une dépendance interdite ?
3	Sécurité et production : autorisation, secrets, logs, migration de schéma, rétrocompatibilité de l'API
4	Tests : couvrent-ils le comportement, pas seulement les lignes ?
5	Lisibilité : noms, taille des méthodes. Le style pur est laissé aux outils (`dotnet format`).

Commenter le code, pas la personne : « cette méthode peut recevoir null » plutôt que « tu as oublié le null ».
Distinguer bloquant et suggestion : préfixe nit: pour le détail non bloquant, question ouverte quand on n'est pas sûr.
Expliquer le pourquoi avec un lien (doc, ADR) : une revue est un moment de formation.
Petites pull requests : au-delà de 400 lignes, la qualité de la relecture chute.

Faire grandir l'équipe Senior

Déléguer le problème, pas la solution : donner le contexte et le critère de réussite, laisser chercher, relire ensemble.
Pair programming sur les sujets délicats (concurrence, migration) plutôt qu'une revue a posteriori.
Écrire : un README de démarrage qui fonctionne, des ADR, une page « comment déboguer en production ».
Rendre l'erreur sûre : environnements de test faciles, rollback simple, post-mortems sans reproche.

Estimer et gérer la dette Confirmé

Une estimation est une fourchette avec ses hypothèses, pas une promesse. Découpez jusqu'à des tâches de moins de deux jours, estimez chacune en optimiste / probable / pessimiste, et annoncez la fourchette. L'estimation à trois points donne une moyenne pondérée : (optimiste + 4 × probable + pessimiste) / 6.

Délibérée et prudente« On livre maintenant et on refactore au sprint suivant. » Acceptable si tracée.

Délibérée et imprudente« Pas le temps pour les tests. » La plus coûteuse.

Involontaire et prudente« Maintenant on sait comment on aurait dû faire. » Normal, apprendre et corriger.

Involontaire et imprudente« C'est quoi une architecture en couches ? » Se traite par la formation.

Quadrant de la dette technique, d'après Martin Fowler.

Tracez la dette comme des tickets ordinaires avec leur coût (« chaque nouvel écran prend un jour de plus à cause de… ») : c'est ce chiffre qui convainc le métier, pas le mot « propre ».

Incidents Confirmé

Stabiliser d'abord : rollback, désactivation par feature flag, montée en capacité. Comprendre vient après.
Communiquer : un responsable de l'incident, des points réguliers aux personnes impactées.
Post-mortem sans reproche : chronologie, cause racine, ce qui a bien marché, actions avec un propriétaire et une date.

Piège

Le héros : le seul à connaître la prod devient le goulot d'étranglement et le point de défaillance unique de l'équipe.
CV-driven development : choisir une techno pour la tester plutôt que pour le besoin.
Dire oui à tout : un senior négocie le périmètre (« on livre A et B vendredi, C la semaine suivante ») plutôt que de promettre l'impossible.

À retenir

Toute décision importante : options, coûts, recommandation, ADR.
La revue de code vise l'exactitude et la transmission, le style est automatisé.
Le succès d'un senior se mesure à ce que l'équipe sait faire sans lui.