Cas avances¶

Équipes distribuées, async-first et processus de décision structures pour les organisations à grande échelle.

Équipes distribuées¶

Une équipe distribuée est une équipe dont les membres travaillent depuis des lieux différents — différents bureaux, différentes villes, ou différents pays avec des fuseaux horaires distincts.

Défis spécifiques¶

Règles de base pour les équipes distribuées¶

1. La camera par défaut : les appels video avec camera activee recreeent une partie de la communication non verbale
2. L'heure commune : identifiez la fenêtre de travail partagee et protegez-la pour les réunions essentielles
3. Remote first, pas remote friendly : si une personne est en remote, tout le monde est en remote (pas de salle ou 5 personnes sont ensemble et 2 sont sur un petit écran)
4. Documentez les décisions immédiatement : après chaque appel, un compte-rendu de 5 lignes dans le wiki

Culture async-first¶

L'async-first ne signifie pas "jamais de synchrone". Cela signifie que le synchrone est l'exception justifiee, pas le reflexe par défaut.

Le principe : ecrivez d'abord¶

Avant d'appeler quelqu'un, posez-vous la question : puis-je écrire ce que j'ai besoin de dire et attendre une réponse ?

graph TD
    B["Besoin de communication"] --> Q1{"Urgent\n(< 1h) ?"}
    Q1 -->|Oui| Q2{"Blocage\nproduction ?"}
    Q2 -->|Oui| SYNC1["Appel immediat\n+ post-incident ecrit"]
    Q2 -->|Non| CHAT["Message chat\navec contexte complet"]
    Q1 -->|Non| Q3{"Complexe ou\nambigu ?"}
    Q3 -->|Oui| DOC["Ecrit structuree\n(issue, RFC, doc)"]
    Q3 -->|Non| ASYNC["Message async\n(issue, commentaire MR)"]

Ce que "bien écrire en async" signifie¶

Un message async efficace contient :

• Le contexte : d'ou vient ce sujet
• La question ou demande précisé : ce dont vous avez besoin
• Les options déjà considérées : ce que vous avez déjà essaye ou analyse
• Une deadline si nécessaire : "j'ai besoin de savoir avant vendredi"

Monorepo vs polyrepo : impact sur la collaboration¶

Le choix de structure de dépôt a un impact direct sur la façon dont les équipes collaborent.

Monorepo¶

Un seul dépôt pour tous les projets de l'organisation (ou d'un domaine).

Avantages pour la collaboration :

• Un seul endroit pour trouver tout le code
• Refactoring global possible en une seule MR
• Dépendances internes toujours à jour
• Conventions de code uniformes plus faciles a enforcer

Défis :

• Les CI doivent être configurees pour ne builder que ce qui a change
• Les accès en lecture peuvent être trop larges
• Les grandes équipes peuvent se marcher dessus sur des branches longues

Polyrepo¶

Un dépôt par service ou composant.

Avantages pour la collaboration :

• Autonomie claire par équipe
• CI simple et rapide par projet
• Onboarding sur un service spécifique plus rapide

Défis :

• Mises à jour de dépendances partagees fragmentees
• Duplication de configuration (CI, linting, conventions)
• Harder to discover ce qu'une autre équipe a déjà construit

Le processus RFC¶

Dans les grandes équipes, les décisions importantes ne peuvent pas être prises en réunion — elles seraient opaques pour tous ceux qui n'etaient pas presents.

Le RFC (Request for Comments) est un processus de décision écrit, asynchrone et transparent.

Cycle de vie d'un RFC¶

stateDiagram-v2
    [*] --> Draft : Auteur redige
    Draft --> Review : Publication dans le depot
    Review --> Accepted : Consensus atteint
    Review --> Rejected : Approche non retenue
    Review --> Draft : Revisions necessaires
    Accepted --> Implemented : Feature livree
    Rejected --> [*]
    Implemented --> [*]

Quand un RFC est nécessaire¶

• Changement d'architecture impactant plusieurs équipes
• Introduction d'une nouvelle dépendance strategique
• Modification d'une API publique ou d'un contrat de service
• Changement de process impactant le workflow de toute l'équipe
• Abandon d'une technologie ou d'un service existant

Quand un RFC n'est pas nécessaire¶

• Implémentation d'une feature dans le périmètre d'une seule équipe
• Bugfix, même complexe
• Mise à jour de dépendance mineure
• Changements de documentation

Frameworks de décision¶

RACI¶

Le RACI clarifie qui fait quoi dans une décision.

Exemple : déploiement d'une nouvelle infrastructure cloud

Consent-based (Sociocracy 3.0)¶

La décision par consentement ne cherche pas le consensus (tout le monde est d'accord) mais l'absence d'objection bloquante (personne n'a d'objection qui mettrait le projet en danger).

Étapes :

1. Proposition partagee à l'écrit
2. Tour de clarifications (pas de debat — juste des questions)
3. Tour de réactions rapides
4. Tour d'objections : une objection est valide si elle argumente un risque concret
5. Intégration des objections dans la proposition

Pratiques par challenge¶

Points clés¶

• Les équipes distribuées ont besoin de règles explicites que les équipes co-localisees peuvent ignorer
• L'async-first réduit la fatigue de réunion mais exige une culture d'écriture forte
• Le choix monorepo/polyrepo a des conséquences directes sur la collaboration — analysez votre contexte
• Le RFC process scale la prise de décision dans les grandes organisations sans bloquer les équipes
• RACI et consent-based sont complementaires : RACI pour la structure, consent pour les décisions collaboratives

Précédent : Bonnes pratiques | Retour a l'index