Software Engineering at Google — reference structurante¶
Resume¶
Livre de reference (O'Reilly 2020, gratuit en ligne) sur les pratiques d'ingenierie logicielle a l'echelle de Google. 25 chapitres organises en Culture, Processus et Outils. These centrale : "software engineering = programming integrated over time". Pas de la veille recente, mais une reference structurante pour formaliser notre methodologie de pilotage projet.
Concepts cles et correspondances ProbatioVault¶
Concepts deja appliques chez nous¶
| Concept Google | Chapitre | Equivalent ProbatioVault |
|---|---|---|
| "Programming integrated over time" | Ch.1 | Thread #10 : "trop mouvant pour un planning fige" — le pilotage projet est du management integre dans le temps |
| Hyrum's Law — tout comportement observable sera dependu | Ch.1 | Bug upload 100MB/500MB (thread #8) — spec locale change, dependants cassent silencieusement. Pipeline Prolog detecte ces contradictions inter-specs |
| Shift Left — detecter le plus tot possible | Ch.1 | Workflow 11 etapes : checks a chaque transition, pas seulement en Gate 8. Verification formelle des step 0/¼/6/8 |
| Beyonce Rule — si le CI devait le catcher, c'est pas la faute de l'infra | Ch.1 | Art. IV CONSTITUTIONAL — Quality Gates JAMAIS contournables |
| Blameless Post-Mortem | Ch.2 | REX step 9 — les erreurs deviennent des learnings indexes et reinjectes. Pas de blame, du compounding |
| Knowledge Sharing — documentation comme outil d'enseignement | Ch.3 | Memoire vivante PD-295 (5 briques), injection unifiee step 0, /learnings, /specs, /contracts |
| Evidence-driven decisions + capacite a les revisiter | Ch.1 | Champ SOURCE sur chaque decision (HUMAN / HUMAN-IA-INPUT). Registre avec historique. Git = audit trail |
| Scaling sublineaire des processus | Ch.1 | Capitalisation learnings (reuse_score tanh). Story 29 : 38% plus rapide et 36% d'ecarts en moins que story 1 |
| Code Review — separation auteur/reviewer | Ch.9 | Art. II CONSTITUTIONAL — l'auteur ne valide jamais son propre travail. Gates croisees Claude/ChatGPT |
| Static Analysis — automated quality checking | Ch.20 | Sonar local Phase 1.5 (bloquant), integrity checks deterministes |
| Continuous Integration — feedback loops | Ch.23 | Pipeline GitLab lint → terraform → ansible → network-check → test → sonar |
Concepts absents chez nous — a adopter¶
1. Deprecation formelle (Ch.15)¶
Google a un processus structure pour deprecer du code, des APIs et des systemes. Chez nous, pas de processus formel pour : - Deprecer des invariants qui ne sont plus pertinents apres evolution de l'architecture - Deprecer des learnings obsoletes (le lifecycle B4 evicte apres 8 semaines sans injection, mais c'est passif — pas de revue active) - Deprecer des specs depassees par des stories ulterieures (le bug upload 100MB est ne de ca)
Action : ajouter une revue de deprecation au REX (step 9). Apres chaque story, identifier les invariants/learnings/specs qui sont invalides par les changements. Les marquer explicitement comme deprecated avec date et raison.
2. Mesure de productivite engineering (Ch.7)¶
Google utilise le framework QUANTS : - Quality of code - Attention from engineers (disruptions, context switches) - iNtellectual complexity - Tempo (velocity, cycle time) - Satisfaction (developer happiness)
Nos metriques (metrics.jsonl) mesurent le workflow de gouvernance (scores gates, nombre d'ecarts, temps par story). Pas la productivite engineering au sens large. On ne mesure pas : - Le temps de context switch entre stories - La satisfaction du "developpeur" (ici : le PO + Claude) - La complexite intellectuelle des stories (au-dela du nombre de modules)
Action : ajouter 2-3 metriques QUANTS dans le compounder. Au minimum : Tempo (temps moyen par etape, pas juste par story) et Quality (ratio ecarts gate 8 v1 vs total ecarts).
3. First Upgrade Problem (Ch.1)¶
Le cout de la premiere mise a jour est toujours sous-estime parce que les hypotheses cachees s'accumulent. Apres une premiere mise a jour douloureuse, les equipes jurent "plus jamais" au lieu de reconnaitre que les suivantes seront moins cheres.
Directement pertinent pour le framework de pilotage (feuille de route Opteven phase 1-2) : la premiere extraction du schema generique sera douloureuse. Les suivantes seront moins cheres. Ne pas abandonner apres la premiere.
4. Fork vs Dependency (Ch.1)¶
Quand forker vs dependre ? Les projets court-terme peuvent forker. Les systemes long-terme doivent eviter les forks sur les formats de serialisation, protocoles et structures de donnees qui traversent les frontieres du projet.
Pertinent pour notre decision MemPalace vs FAISS : MemPalace est une dependance externe (50K stars, activement maintenu). FAISS est plus simple mais nous rend responsables de tout. Pour un outil interne long-terme, la dependance est plus risquee que le fork si elle evolue dans une direction qui ne nous convient pas.
Chapitres a lire en priorite¶
| Priorite | Chapitre | Raison |
|---|---|---|
| 1 | Ch.15 Deprecation | Concept absent chez nous, directement applicable |
| 2 | Ch.7 Measuring Engineering Productivity | Enrichir nos metriques compounder |
| 3 | Ch.3 Knowledge Sharing | Comparer avec notre systeme de capitalisation |
| 4 | Ch.9 Code Review | Benchmark nos gates croisees vs le processus Google |
| 5 | Ch.11-14 Testing | Benchmark notre step 2 (tests) + step 7 (acceptabilite) |
Pertinence pour la methodologie de pilotage¶
Ce livre est une reference structurante pour la phase 5 de la feuille de route (formaliser la methodologie). Plusieurs concepts sont directement transposables :
- "Programming integrated over time" → "Pilotage integre dans le temps" (notre temporal engine)
- Hyrum's Law → justification de la verification formelle inter-specs (notre pipeline Prolog)
- Shift Left → justification des checks a chaque transition (pas seulement en fin de workflow)
- Blameless Post-Mortem → justification du REX comme outil d'apprentissage, pas de blame
- Scaling sublineaire → justification de la capitalisation learnings avec reuse_score
Le livre ne couvre pas le pilotage de projet assiste par IA (ecrit en 2020, avant les LLM en prod). Mais les principes d'ingenierie sont les memes — notre contribution est de les appliquer au pilotage, pas au code.