Fondamentaux¶
Pourquoi collaborer, les coûts des silos et les bases d'une culture d'équipe efficace.
Pourquoi la collaboration est une compétence technique¶
Écrire du code est rarement un acte solitaire. Dans une équipe, chaque ligne produite sera lue, modifiée, debuggee ou supprimée par quelqu'un d'autre — souvent vous-même dans six mois.
La collaboration n'est pas un bonus social : c'est une pratique d'ingénierie qui réduit le risque, accéléré l'apprentissage et produit un code plus robuste.
Le bus factor¶
Le bus factor (ou truck factor) mesure combien de personnes doivent être absentes pour que le projet soit en danger.
Bus factor = 1 → un seul dev connait ce composant critique
Bus factor = 3 → il faut perdre 3 personnes simultanement pour bloquer
Bus factor 1
Un bus factor de 1 sur un composant critique signifie qu'une seule demission, maladie ou conge peut bloquer une équipe entière. C'est un risque opérationnel mesurable.
Mesurer son bus factor¶
- Listez les composants critiques du système
- Pour chaque composant, identifiez combien de personnes peuvent intervenir dessus sereinement
- Tout composant avec un seul expert est une dette a rembourser
Les silos de connaissance¶
Un silo de connaissance se forme quand une information ou une compétence est concentree chez une seule personne ou équipe sans mécanisme de partage.
Coûts concrets des silos¶
| Coût | Manifestation |
|---|---|
| Travail en double | Deux équipes reinventent la même solution sans le savoir |
| Décisions incoherentes | Chaque silo choisit ses propres standards, la base de code diverge |
| Onboarding lent | Les nouveaux ne savent pas a qui poser leurs questions |
| Blocages en cascade | Une personne absente bloque plusieurs livraisons |
| Perte de contexte | Le "pourquoi" d'une décision disparait avec la personne qui l'a prise |
Signaux d'alerte¶
- "Seul Alice peut toucher ce module"
- "On a pose la question en réunion mais personne ne sait"
- "On a refait ce qu'une autre équipe avait déjà fait"
- "Le code legacy n'est plus maintenable car l'auteur est parti"
Culture d'équipe : les fondations¶
Sécurité psychologique¶
La sécurité psychologique (Amy Edmondson, 1999) est la conviction partagee que l'on peut exprimer des idées, poser des questions ou signaler des erreurs sans risque de punition.
Sans sécurité psychologique :
- Les devs ne signalent pas les problèmes tôt
- Les reviews deviennent des jugements de valeur
- Les erreurs sont cachees plutôt que corrigees
Construire la sécurité psychologique
Commencez par vous-même : posez des questions ouvertement, admettez vos erreurs en public, remerclez ceux qui signalent des problèmes.
Culture blameless¶
La culture blameless séparé les erreurs des personnes. Quand un bug atteint la production, la question n'est pas "qui a fait ca ?" mais "comment notre système a permis que ca arrive ?".
Outils : post-mortems sans blame, rétrospectives orientees processus, mesures preventives système.
Collaboration synchrone vs asynchrone¶
graph LR
A["Besoin de collaboration"] --> B{"Urgent et complexe ?"}
B -->|Oui| C["Synchrone\n(appel, pair programming)"]
B -->|Non| D["Asynchrone\n(MR, commentaire, doc)"]
C --> E["Documenter la decision"]
D --> F["Reponse sous X heures\n(accord d'equipe)"]Quand choisir chaque mode¶
| Mode | Avantages | Limites |
|---|---|---|
| Synchrone | Résout l'ambiguite vite, crée du lien | Coute cher en temps, exclut les fuseaux horaires distants |
| Asynchrone | Laisse du temps de réflexion, archive | Peut être lent, nécessité une culture d'écriture |
Outils de collaboration¶
La forge (GitLab, GitHub, Gitea)¶
La forge est le hub central : code, issues, MR, pipelines, wiki. C'est la source de vérité pour les décisions techniques.
Chat d'équipe (Slack, Mattermost, Teams)¶
Utile pour les échanges rapides. Attention : les décisions prises en chat sont invisibles pour les futurs membres. Documentez-les ailleurs.
Wiki et documentation¶
Un wiki vivant (Confluence, Notion, MkDocs) preserves le contexte. Trop souvent abandonne après six mois — automatisez sa mise à jour.
Video (Zoom, Meet, Jitsi)¶
Pour les rétrospectives, les reviews de design, le pair programming remote. Activez la camera quand possible : ca humanise les échanges.
Modèle de maturité collaborative¶
graph TD
N0["Niveau 0 : Isolation\nChacun travaille seul\nPas de reviews, pas de docs"] --> N1
N1["Niveau 1 : Coordination\nReviews occasionnelles\nDoc minimale"] --> N2
N2["Niveau 2 : Cooperation\nReviews systematiques\nConventions partagees"] --> N3
N3["Niveau 3 : Collaboration\nPair programming, inner source\nKnowledge sharing actif"] --> N4
N4["Niveau 4 : Co-creation\nCulture blameless\nContribution cross-equipe fluide"]
style N0 fill:#c0392b,color:#fff
style N1 fill:#e67e22,color:#fff
style N2 fill:#f1c40f,color:#000
style N3 fill:#27ae60,color:#fff
style N4 fill:#2980b9,color:#fff| Niveau | Caractéristiques clefs | Signal de progression |
|---|---|---|
| 0 — Isolation | Code non versionne ou chacun sur sa branche eternelle | Adoption de Git + MR |
| 1 — Coordination | Reviews ad hoc, pas de standard | Reviews systematiques sur toutes les MR |
| 2 — Cooperation | Conventions documentees, CI verte obligatoire | Onboarding < 1 jour sur un nouveau projet |
| 3 — Collaboration | Pair programming régulier, tech talks internes | Bus factor > 2 sur tous les composants clés |
| 4 — Co-création | Post-mortems blameless, contributions cross-équipe ouvertes | N'importe qui peut contribuer à n'importe quel projet |
Points clés¶
- Le bus factor est une métrique de risque : mesurez-le, reduisez-le
- Les silos ont un coût financier et humain direct
- La sécurité psychologique est un prérequis, pas un nice-to-have
- Documentez les décisions prises en synchrone dans un outil persistant
- La maturité collaborative se construit graduellement — commencez par les reviews
Suite : Code review