Rôles et Responsabilités

Ce document définit les rôles clés dans la méthodologie Développement par Contraintes Convergentes (DC²) et leurs responsabilités spécifiques à travers les 6 phases. DC² est conçu pour s’adapter à différentes structures d’équipe, des startups aux grandes entreprises.

Philosophie des Rôles

DC² privilégie la flexibilité organisationnelle : Les rôles décrits ici sont des responsabilités, pas des titres de poste rigides. Une même personne peut occuper plusieurs rôles, et un rôle peut être partagé entre plusieurs personnes selon la taille et la structure de votre équipe.

Principe clé : Ce qui importe n’est pas qui porte le titre, mais qui assume la responsabilité à chaque phase.

Vue d’Ensemble des Rôles

Note sur la Répartition du Travail

Les descriptions “Humain décide, LLM génère” dans le tableau ci-dessous indiquent le rôle dominant de chaque partie dans la phase. Elles ne sont pas des métriques à mesurer.

L’objectif est de produire les livrables de qualité requis par chaque phase, peu importe le temps que chaque partie y contribue. Une équipe qui passe 80% de son temps à guider le LLM en Phase 2A n’échoue pas — elle adapte simplement son approche à son contexte et à sa maturité.

Ce qui compte : Les livrables de la phase respectent le Definition of Done. Ce qui ne compte pas : Le temps exact passé par le humain vs le LLM.

Rôle Principal par Phase

Définition des Rôles

1. Concepteur

Qui peut jouer ce rôle :

• Architecte logiciel (idéal)
• Analyste technique senior
• Tech Lead expérimenté
• Développeur senior avec talent de conception

Responsabilités principales :

• Traduire besoins business en décisions architecturales
• Identifier contraintes techniques et compromis
• Créer et documenter les ADR (Architecture Decision Records)
• Valider que les solutions proposées répondent aux objectifs stratégiques
• Guider l’équipe dans la compréhension de la vision architecturale

Compétences requises :

• Vision système (comprendre comment les composants s’interconnectent)
• Expérience avec patterns architecturaux et trade-offs
• Capacité d’articuler décisions techniques pour audience business
• Jugement sur scalabilité, performance, maintenabilité

Engagement temps :

• Phase 1 : ⏱️⏱️⏱️ - Rôle principal
• Phase 2 : ⏱️⏱️ - Génération + transfert critique
• Phases 3-6 : ⏱️ - Disponibilité consultation

2. Product Owner

Qui peut jouer ce rôle :

• Product Owner Scrum/Agile
• Product Manager
• Business Analyst senior
• Chef de produit

Responsabilités principales :

• Définir les critères de succès business
• Prioriser les fonctionnalités et arbitrer les compromis
• Valider que la solution répond aux besoins métier
• Représenter les utilisateurs finaux et stakeholders
• Approuver le plan tactique avant développement

Compétences requises :

• Connaissance profonde du domaine métier
• Capacité de priorisation et arbitrage
• Communication entre technique et business
• Vision produit et roadmap

Engagement temps :

• Phase 1 : ⏱️⏱️ - Validation continue
• Phase 2B : ⏱️ - Transfert Critique
• Phase 6 : ⏱️ - Validation finale optionnelle

3. Développeur Senior

Qui peut jouer ce rôle :

• Développeur avec 5+ ans expérience
• Tech Lead technique
• Senior Software Engineer
• Développeur avec expertise domaine spécifique

Responsabilités principales :

• Valider qualité et complétude des tests (Phase 3)
• Valider justesse implémentation (Phase 4)
• Guider l’équipe dans le refactoring (Phase 5)
• Valider résultats des inspections (Phase 6)
• Mentor technique pour développeurs moins expérimentés

Compétences requises :

• Expertise technique approfondie du stack technologique
• Expérience TDD et qualité code
• Capacité de mentorat et transmission de connaissances
• Jugement sur maintenabilité et évolution long terme

Engagement temps :

• Phase 3 : ⏱️ - Validation tests
• Phase 4 : ⏱️ - Validation implémentation
• Phase 5 : ⏱️⏱️⏱️ - Guidance refactoring continue
• Phase 6 : ⏱️ - Validation inspections

4. Équipe de Développement

Qui peut jouer ce rôle :

• Développeurs de tous niveaux (junior à senior)
• L’équipe complète assignée au projet
• Peut inclure spécialistes (frontend, backend, data, etc.)

Responsabilités principales :

• Réviser et challenger le plan tactique (Phase 2B)
• Identifier risques et dépendances techniques
• Exécuter le refactoring sous guidance senior (Phase 5)
• Réviser et approuver les inspections (Phase 6)
• Développer ownership collectif du code

Compétences requises :

• Compétences techniques dans le stack du projet
• Capacité de travail collaboratif
• Volonté d’apprendre et d’améliorer
• Pensée critique (challenger hypothèses)

Engagement temps :

• Phase 2 : ⏱️⏱️ - Pré-lecture plan tactique et Transfert Critique
• Phase 4 : ⏱️ - Génération
• Phase 5 : ⏱️⏱️⏱️ - Travail refactoring actif
• Phase 6 : ⏱️ - Révision inspections

Dynamiques de Collaboration

Phase 1 : Architecture Stratégique

graph LR
    C[Concepteur lead] <--> PO[Product Owner]
    C --> D[Documents ADR + Schémas]
    D --> V[Validation conjointe]

Dynamique : Dialogue itératif entre vision technique et besoins business. Le Concepteur propose des solutions, le PO valide l’alignement business.

Phase 2A-2B : Plan Tactique + Transfert Critique

Phase 2A : Génération Plan

graph TD
    CL[Concepteur + LLM] --> PT[Plan Tactique]
    PT --> ED[Équipe Dev pré-lecture]

Phase 2B : Transfert Critique

graph TD
    CP[Concepteur présente] --> EDC[Équipe Dev challenge]
    EDC --> DC[Discussion collective]
    DC --> PR[Plan révisé approuvé]

Dynamique clé : Le Transfert Critique (Phase 2B) est le moment où la vision du Concepteur rencontre la réalité de l’équipe. L’équipe DOIT challenger activement - une équipe passive signale un problème.

Red flags :

• Équipe silencieuse (pas de questions/préoccupations)
• Approbation tampon sans discussion
• Estimations divergentes > 50% entre Concepteur et Équipe

Phase 3-4 : TDD RED-GREEN

graph TD
    DSL[Dev Senior + LLM] --> T[Tests Phase 3]
    T --> VS[Validation Senior]
    VS --> DLI[Dev + LLM → Implémentation Phase 4]
    DLI --> VS2[Validation Senior]

Dynamique : Phases rapides, fortement automatisées. Senior valide mais ne code pas directement. Focus sur rapidité avec qualité garantie par tests.

Phase 5 : Refactoring (Dynamique Centrale)

graph TD
    DS[Dev Senior guide] --> DP[Définit priorités]
    DP --> ED[Équipe Dev exécute]
    LLM[LLM assiste] --> ED
    ED --> D1[Dev1]
    ED --> D2[Dev2]
    ED --> D3[Dev3]
    D1 --> RP[Refactor parallèle]
    D2 --> RP
    D3 --> RP
    RP --> RC[Senior révise continu]
    RC --> AF[Approbation finale]

Dynamique clé :

• Senior ne fait PAS tout le travail seul
• Senior identifie opportunités : “Ce module a de la duplication, qui veut l’extraire ?”
• Équipe propose approches : “On pourrait utiliser pattern Strategy ici ?”
• Senior guide : “Bonne idée, mais attention au sur-engineering.”
• Équipe implémente sous guidance
• Senior révise et ajuste en continu

Bénéfices :

• Perfectionnement par la pratique (équipe développe compétences)
• Scalabilité (plusieurs refactorings parallèles)
• Ownership (équipe fière du résultat)
• Senior multiplicateur de force (guide 3-4 personnes simultanément)

Anti-pattern à éviter :

• Senior fait tout, équipe regarde → Pas d’apprentissage, goulot d’étranglement
• Équipe seule sans guidance → Risque sur-engineering ou sous-refactoring

Phase 6 : Triple Inspection

graph TD
    LLM[LLM exécute 3 inspections] --> R[Rapports générés]
    R --> ERC[Équipe révise collectivement]
    ERC --> SVP[Senior valide priorisation]
    SVP --> DA[Décisions actions]

Dynamique : Inspections automatisées, décisions humaines. L’équipe apprend à lire et interpréter rapports d’inspection, Le senior valide que la priorisation est appropriée.

Exemple : Mode Collaboratif pour Phase 5

Certaines équipes organisent Phase 5 selon un mode collaboratif qui combine scalabilité et apprentissage. Voici comment ce mode fonctionne :

Principe

• Senior identifie les opportunités de refactoring
• Équipe exécute les refactorings (en parallèle si plusieurs développeurs)
• Senior reste disponible pour questions et revue continue
• Focus sur apprentissage par la pratique

Avantages de ce mode

• Scalabilité : Plusieurs refactorings en parallèle au lieu de séquentiel
• Apprentissage : Équipe développe compétences par la pratique
• Ownership : Équipe fière du résultat, pas juste exécutante
• Senior multiplicateur : Guide plusieurs personnes simultanément au lieu de tout faire seul

Progression typique

Sprint 1-2 : Senior investit temps (guidance intensive) Sprint 3-4 : Breakeven (temps comparable au senior solo) Sprint 10+ : ROI positif (équipe autonome, senior libéré pour architecture)

Quand considérer ce mode

• Équipe de 3+ développeurs
• Objectif d’apprentissage et montée en compétences
• Projets avec durée de vie longue (>1 an)
• Senior disponible pour guidance continue

Alternatives

Ce mode n’est pas obligatoire. D’autres approches fonctionnent :

• Senior solo : Rapide pour équipes <3 personnes ou refactorings simples
• Pairing : Senior + 1 dev, transfert de connaissance intense
• Revue asynchrone : Équipe propose, senior revoit, itération

Choisissez l’approche qui correspond à votre contexte organisationnel.

Adaptation Selon Taille d’Équipe

Startup / Petite Équipe (2-4 personnes)

Mapping typique :

• Tech Founder : Concepteur + Dev Senior
• Dev 1-2 : Équipe Dev
• Founder/PM : Product Owner

Ajustements :

• Même personne joue plusieurs rôles
• Transfert Critique moins formel (discussion d’équipe)
• Phase 5 : Tech Founder guide mais participe aussi au refactoring
• Décisions plus rapides, moins de documentation formelle

Exemple concret :

• Phase 1 : Tech Founder (2h) définit architecture avec PM
• Phase 2B : Discussion équipe 60min autour table
• Phase 5 : Tech Founder + Dev1 refactor ensemble, pairing

Équipe Moyenne (5-10 personnes)

Mapping typique :

• Architecte/Tech Lead : Concepteur
• Senior Dev (2-3) : Dev Senior (peuvent se partager)
• Dev (3-5) : Équipe Dev
• Product Owner : Product Owner

Ajustements :

• Rôles plus spécialisés mais toujours flexibles
• Transfert Critique formel avec agenda structuré
• Phase 5 : 2-3 refactorings parallèles sous guidance Seniors
• Documentation complète mais pragmatique

Exemple concret :

• Phase 2B : Réunion formelle 90min, tous présents
• Phase 5 :
  • Senior1 guide Dev1+Dev2 sur Module A
  • Senior2 guide Dev3+Dev4 sur Module B
  • Revue commune fin journée

Grande Équipe (10+ personnes)

Mapping typique :

• Architecte Principal : Concepteur
• Tech Leads (2-3) : Concepteurs assistants
• Senior Dev (4-6) : Dev Senior
• Dev (10+) : Équipe Dev
• Product Manager + BAs : Product Owner (collectif)

Ajustements :

• Hiérarchie plus formelle nécessaire
• Transfert Critique par sous-équipes avec synthèse
• Phase 5 : Multiples refactorings parallèles, coordination essentielle
• Documentation extensive, processus formalisés

Exemple concret :

• Phase 1 : Architecte Principal + 2 Tech Leads co-créent
• Phase 2B :
  • 3 sessions Transfert (une par sous-équipe)
  • Session consolidation finale
• Phase 5 :
  • 4 groupes parallèles (Senior + 2-3 Devs chacun)
  • Sync quotidien 30min tous Seniors

Matrice de Compétences

Compétences par Rôle

Pièges Courants

1. Concepteur Isolé

Problème : Concepteur décide seul, équipe exécute aveuglément Solution : Transfert Critique obligatoire (Phase 2B), équipe challenge activement

2. Senior Fait Tout

Problème : Senior code tout le refactoring, équipe passive Solution : Senior guide, équipe exécute. Apprentissage > vitesse court terme

3. Rôles Rigides

Problème : “Je suis Dev, pas Senior, donc je ne peux pas commenter l’architecture” Solution : Encourager contribution tous niveaux. Junior peut avoir insights précieux.

4. Product Owner Absent

Problème : PO pas impliqué Phase 1-2, découvre résultat Phase 6 Solution : PO valide à Phase 1 et Phase 2B minimum. Pas de surprises tardives.

5. Équipe Non Challengeante

Problème : Équipe approuve tout au Transfert Critique sans questions Solution : Créer culture sécurité psychologique. Questions = force, pas faiblesse.

Indicateurs Santé Rôles

Signaux Positifs

• Équipe pose plusieur questions lors du Transfert Critique
• Estimations Concepteur vs Équipe divergent < 20%
• Juniors contribuent aux idées de refactoring Phase 5
• Product Owner valide sans surprise Phase 2B

Signaux Négatif

• Équipe silencieuse au Transfert Critique
• Estimations divergent >50%
• Senior code la majorité du refactoring seul
• Product Owner découvre solution en Phase 6
• “C’est pas mon rôle” répété fréquemment

Recommandations Finales

1. Flexibilité > Rigidité : Adaptez les rôles à votre contexte organisationnel
2. Responsabilité > Titre : Ce qui compte c’est qui fait quoi, pas les cartes de visite
3. Collaboration > Hiérarchie : Encouragez contribution tous niveaux
4. Apprentissage > Vitesse : Phase 5 en équipe plus lente initialement mais ROI long terme
5. Ownership Collectif : Équipe entière responsable qualité, pas juste Senior/Concepteur

DC² fonctionne mieux quand les rôles sont des responsabilités partagées avec leadership clair, pas des silos étanches.