Matrice RACI projet
Ce document décrit les interactions entre les rôles de l’équipe Edu-team aux différentes étapes du cycle de vie du logiciel, sous la forme d’une matrice RACI. Il sert de référence pour tout futur arrivant et pour la résolution des arbitrages de responsabilité sur les activités du projet.
Posture
La matrice ci-dessous décrit le dispositif retenu par l’équipe. Elle est tenue à jour à mesure que de nouvelles activités émergent ou que les responsabilités évoluent.
1. Codes utilisés
| Code | Signification | Description |
|---|---|---|
| R | Responsible, responsable de l’exécution | Réalise effectivement le travail |
| A | Accountable, responsable final | Rend des comptes et dispose du dernier mot ; un seul par activité |
| C | Consulted, consulté | Sollicité pour avis avant la décision ou la production |
| I | Informed, informé | Tenu au courant après réalisation |
2. Légende des colonnes
Les colonnes représentent les domaines de référence décrits dans les fiches de poste, et non des rôles fixes attribués à une seule personne. À l’intérieur de chaque pôle (Dev ou Ops), tout membre peut contribuer (R) à n’importe quelle activité. Le titulaire d’un domaine est en revanche systématiquement responsable final (A) sur les sujets relevant de son périmètre.
| Code | Domaine de référence | Pôle |
|---|---|---|
| PO | Product Owner du sprint (rôle agile en rotation) | Agile (rotation) |
| SM | Scrum Master du sprint (rôle agile en rotation, gardien de la méthodologie Scrum) | Agile (rotation) |
| DF | Domaine Interface utilisateur et expérience utilisateur | Dev |
| DB | Domaine Architecture et couche serveur | Dev |
| OP | Domaine Plateforme et IaC | Ops |
| OR | Domaine Architecte Réseau et accès distants | Ops |
| OE | Domaine Plateforme et supervision | Ops |
| OS | Domaine Sécurité et CI/CD | Ops |
| RP | Référents pédagogiques DIIAGE (externe) | Externe |
À propos du domaine Polyvalence front-back et tests : le titulaire de ce domaine contribue de façon transversale aux colonnes DF et DB. Il est responsable final sur les activités #14 et #15 (stratégie et tests d’intégration / tests de bout en bout) ; sur les autres lignes, sa contribution est implicite dans DF et DB.
3. RACI sur le cycle de vie complet
| # | Activité / Livrable | PO | SM | DF | DB | OP | OR | OE | OS | RP |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Recueil et analyse du besoin | A | I | R | C | C | C | C | C | R |
| 2 | Écriture des récits utilisateurs et critères d’acceptation | C | I | A/R | C | C | C | C | C | C |
| 3 | Conception d’architecture | C | I | C | A/R | R | C | R | C | I |
| 4 | Décisions transverses (ADR) | C | I | C | A | C | C | C | C | I |
| 5 | Planification de sprint et priorisation | A/R | R | C | C | C | C | C | C | C |
| 6 | Développement de l’interface utilisateur | I | I | A/R | C | I | I | I | C | I |
| 7 | Développement de la couche serveur et gRPC | I | I | C | A/R | I | I | I | C | I |
| 8 | Exploitation et maintien du cluster Proxmox | I | I | I | C | R | C | A/R | C | I |
| 9 | Infrastructure en tant que code et automatisation | I | I | I | C | A/R | C | R | R | I |
| 10 | Pipelines CI/CD et contrôles qualité (K3S, ArgoCD) | I | I | C | C | C | I | C | A/R | I |
| 11 | Sécurité applicative et infrastructure | I | I | C | C | C | R | C | A/R | I |
| 12 | Supervision et alertes (Prometheus, Grafana, Loki) | I | I | I | I | C | C | A/R | C | I |
| 13 | Architecture et exploitation du réseau (Mikrotik) | I | I | I | C | C | A/R | R | C | I |
| 14 | Stratégie et tests d’intégration (référent qualité responsable final) | C | I | R | R | I | I | I | C | I |
| 15 | Tests de bout en bout et recette (référent qualité responsable final) | C | I | R | R | C | C | C | C | C |
| 16 | Documentation produit, procédures d’exploitation, ADR | C | I | R | R | R | A/R | R | R | I |
| 17 | Revue de sprint et démonstration | A/R | R | R | R | R | R | R | R | C |
| 18 | Rétrospective | I | A/R | R | R | R | R | R | R | I |
| 19 | Mise en service de la première version | A | I | R | R | R | R | R | R | C |
| 20 | Support utilisateur post-livraison | C | I | C | C | C | C | A/R | C | C |
4. Lecture du RACI : trois principes structurants
Trois principes guident la matrice :
4.1 Un seul responsable final par activité
Cette règle, scrupuleusement appliquée, évite la dilution des responsabilités fréquente dans les petites équipes pluri-spécialisées. À chaque instant, l’équipe sait qui tranche en cas de désaccord.
4.2 Dev et Ops en parallèle
Les activités 6 à 13 montrent comment les pôles Dev et Ops avancent en parallèle : deux responsables finaux distincts coexistent sur la même période, tout en se consultant mutuellement (présence de C croisés). Ce parallélisme est rendu possible par ce maillage de consultations bidirectionnelles, sans qu’un développeur ait à prendre une tâche d’Ops ou inversement.
4.3 Participation collective à la qualité et à la documentation
Les activités 14 à 17 mobilisent l’ensemble de l’équipe avec un responsable final clair (le référent qualité pour les tests, le titulaire du domaine Réseau (OR) pour la documentation transverse, le PO pour la revue de sprint, le SM pour la rétrospective). Cette répartition matérialise la culture « vous le construisez, vous le supportez » et garantit que personne ne se décharge des tâches transverses.
5. Interactions avec les référents pédagogiques
Au-delà du RACI interne, l’équipe entretient un flux d’interaction structuré avec les référents pédagogiques DIIAGE :
- Points de cadrage en début de phase de besoin : compréhension fine des attentes pédagogiques, formalisation conjointe des récits utilisateurs.
- Démonstration en fin de sprint : présentation des incréments, retours immédiats, validation des parcours pédagogiques.
- Remontée des retours terrain au fil de l’eau : les enseignants signalent en continu les ajustements à apporter, qui sont consolidés en entrée de la planification de sprint suivante.
6. Voir aussi
- Les fiches de poste qui détaillent chaque rôle.
- La Definition of Done qui précise les attendus de chaque livrable.
- La Definition of Ready qui précise les attendus en entrée de sprint.
- Le Workflow Git qui définit les règles de collaboration sur le code.
- La Stratégie de tests qui structure la qualité (référent qualité responsable final).
- L’index des ADR qui matérialise les décisions transverses (activité #4).