Réunion d'architecture collective, groupe 2

Date : 31 août 2026, 15h06 à 15h33 (26 min 28 s) Objet : convergence des six architectures individuelles EC01 vers une architecture de groupe Source : Voix 260831_150633.m4a, transcrite par Whisper large-v3-turbo Participants : les six membres du groupe 2. Lénaïc BARBIER tient le rôle de Tech Lead.

Fiabilité de la transcription. L'enregistrement est une prise de salle avec recouvrements de parole. Les noms d'outils ont été rétablis depuis le contexte projet : « VJS » pour Vue.js, « Python face d'API » pour FastAPI, « K-Clock » pour Keycloak, « TAMISCALDB » pour TimescaleDB, « Siebel » pour Ansible, « six clés saupes plus age » pour SOPS et age, « scan 3D » pour Trivy, « WASP » pour OWASP, « Mignot » pour le Mock IoT. Les passages incertains sont signalés. L'attribution par locuteur n'est pas fiable sur cet enregistrement et n'est donc pas reportée : les noms cités ci-dessous ne le sont que là où la bande les nomme explicitement.

---

1. Décisions actées

Brique	Retenu	Motif entendu en séance
Proxy	Caddy	Choisi par plusieurs dossiers individuels, configuration statique, « facile à configurer »
Front / dashboard	Vue.js, porté par Olivier	Compétence déjà présente dans l'équipe
API	FastAPI (Python)	Présent dans les six dossiers, « on ne va pas révolutionner »
Base applicative	PostgreSQL, extension TimescaleDB	Volumes en temps réel, interrogation légère, indexation
Registre de modèles	MLflow	Lit les modèles entraînés dans le stockage objet
Supervision	Prometheus et Grafana	Accord unanime, expérience existante
Source de données	API Mock IoT fournie	Imposée par le cadrage
Collecte	cron toutes les minutes, pipeline ETL simple	Volume faible, « pas besoin de plugins de flux massifs »
Branches	main, develop, une branche par fonctionnalité	Proposé et accepté sans opposition
Fusion	Modèle de demande de fusion obligatoire	À rédiger
Relecture	Tech Lead (Lénaïc) + un relecteur tiré au sort, obligatoire	« il faut que tout le monde connaisse tout le projet »
Preuve	Une preuve par demande de fusion (capture d'écran, pipeline, test)	Sert les preuves individuelles exigées quotidiennement
Chaîne d'intégration	Pipeline de tests et de qualité sur develop, rejouée sur main
Canal	Teams	Imposé par l'école, Discord écarté comme canal officiel

Décisions négatives explicites

• Pas de coffre à secrets dans le cloud. L'idée d'un Vault hébergé a été posée puis écartée en séance : « si un jour Azure est down, on n'a plus les secrets, on ne peut plus lancer le projet ». La dépendance a été jugée trop forte. Les secrets restent locaux.
• Pas de full cloud. Formulation entendue : « on part sur pas du full Azure ».

---

1 bis. Décisions prises après la réunion

Arbitrées par le Tech Lead le 31 août, hors séance. Elles ferment deux des points laissés ouverts. À faire valider au prochain point d'équipe.

Sujet	Décision	Ce qu'elle ferme
Authentification	Keycloak auto-hébergé	§2.1
Stockage	Médaillon complet bronze / argent / or dans le data lake, PostgreSQL conservé pour l'applicatif	§2.2
Moteur du lac	MinIO, stockage objet compatible S3, hébergé sur le serveur	§2.2

Sur l'authentification, les consignes ne contraignent rien. EADL - 01 - Sujet Officiel : « Les choix technologiques sont libres. Vous devez justifier vos choix dans le dossier de conception. » Les seules obligations portent sur le contenu et la preuve : EC01 doit couvrir « Sécurité by design (authentification, secrets, surface d'attaque) », et EC04 est noté sur « IAM configuré, secrets gérés, audit de sécurité documenté ».

Le « IAM configuré » d'EC04 relève de la rubrique Cloud, donc de l'IAM du fournisseur, et non de l'authentification applicative. L'identité applicative Azure à privilège minimal prévue au dossier suffit à le couvrir, sans faire dépendre la connexion des utilisateurs d'Azure. Les deux sujets restent séparés.

Conséquences à traiter

Keycloak reste local, donc aucune dépendance de fonctionnement au cloud : le raisonnement appliqué au Vault vaut aussi ici, et il est respecté. Le prix est un conteneur et une base supplémentaires sur un hôte de 8 Go partagé à six. Trois points à régler : la base de Keycloak est-elle la même instance PostgreSQL avec un schéma dédié ou une instance séparée, la configuration du domaine de sécurité est-elle décrite en code plutôt que cliquée, et qui l'administre.

Le médaillon combiné à Keycloak vide PostgreSQL. Keycloak prend les comptes, le lac prend le brut et le traité, et on retombe sur le « PostgreSQL ne sert à rien » de la réunion par un autre chemin. Or le tableau de bord doit rendre une série de 24 heures sous 400 ms, et interroger du Parquet à chaque clic ne tient pas cette cible.

Motif retenu : le lac garde l'historique complet en trois zones, et la zone or est matérialisée dans PostgreSQL avec TimescaleDB pour servir l'application. Le médaillon est préservé, la latence aussi, et la jointure d'auditabilité entre valeur reçue et valeur reconstituée reste faisable en une requête.

Il reste que même avec Keycloak, une table locale doit associer l'identifiant Keycloak à un rôle et à des sites : l'autorisation par ressource ne se délègue pas à un fournisseur d'identité qui ignore vos sites.

La supervision ne peut pas lire le lac directement

La réunion a laissé la question en « oui je crois, de mémoire, à revérifier ». Vérification faite, la réponse est non, dans les deux cas.

Prometheus ne lit aucun stockage objet. C'est un collecteur qui tire : il interroge des points d'entrée /metrics exposés par les services et range le résultat dans sa propre base locale. La seule relation avec du stockage objet va dans l'autre sens, Thanos ou Mimir expédiant les blocs vers du S3 pour de la rétention longue. C'est un composant supplémentaire, et c'est pour archiver, pas pour lire. À noter aussi que Prometheus porte des métriques techniques, pas les mesures de consommation, qui sont des données métier.

Grafana n'a pas de source de données MinIO native. Tracer du Parquet demande un moteur de requête intermédiaire, DuckDB, Trino ou ClickHouse, ou le greffon communautaire Infinity. Chacun est un conteneur de plus sur un hôte qui ne sait pas créer de réseau Docker et dont les 8 Go sont partagés à six.

Répartition retenue :

Ce qui est affiché	Source	Coût
Consommation, prévisions, qualité des données	PostgreSQL et TimescaleDB, zone or matérialisée	Source native Grafana, aucun composant ajouté
Latence, collecte, santé des conteneurs	Prometheus	Son usage prévu
Historique complet, réentraînement, artefacts MLflow	MinIO	Lu par l'ETL et par MLflow, jamais par Grafana

C'est ce qui justifie la zone or matérialisée en base : elle rend le tableau de bord possible sans ajouter Trino.

Exploitation de MinIO. Deux ports à inscrire au plan d'adressage, 9000 pour l'API et 9001 pour la console. Et une politique de rétention dès le départ : 48 Go libres sur un disque partagé à six, et le médaillon conserve trois fois la même donnée sous trois formes. MinIO convient nativement comme magasin d'artefacts MLflow, dont la base de suivi reste sur PostgreSQL.

Sur le front, en attente d'arbitrage

Vue.js est retenu. Une application monopage n'a pas de couche serveur, donc le jeton est rangé dans le navigateur, lisible par tout script qui s'y exécute. Keycloak parle OIDC et sait fonctionner en client confidentiel, où le jeton ne quitte jamais le serveur : autant s'en servir.

Option recommandée : Vue en monopage plus un mandataire dans FastAPI qui détient le jeton et pose un cookie httpOnly. Olivier garde Vue, l'équipe reste en Python, et aucun conteneur n'est ajouté. Nuxt donne la même propriété de façon plus directe, au prix d'un service Node de plus.

---

2. Décisions non tranchées

Ce sont les points qui sont restés ouverts à la fin de la réunion. Chacun porte ce qu'il faut pour le fermer.

2.1 Authentification — tranché depuis, voir §1 bis

Décision : Keycloak auto-hébergé. Ce qui suit est le compte rendu de la séance, conservé parce qu'il porte le motif.

La réunion s'est terminée sans décision. Trois positions coexistaient : Keycloak, Azure Entra ID, et des jetons émis par l'API.

Ce qui a été dit et qui n'a pas été résolu :

• Plusieurs membres rapportent que leur propre analyse EC01 concluait que l'authentification ne devait pas être dans le cloud. Personne n'a su dire pourquoi.
• L'argument avancé pour Entra ID est explicitement pédagogique : « comme ça au moins on a du cloud et on a de l'authentification », « on montre qu'on est capable de faire les deux ». Un membre a immédiatement objecté : « comment tu expliques au jury… on a une compétence et je l'ai validée ? Ça fait un peu bizarre. »
• Le débat s'est clos sur un report : « ça sera peut-être les consignes qui trancheront ».

Ce qui manque pour trancher, dans cet ordre :

1. Avez-vous le droit de créer une app registration dans le tenant Azure de l'école ? Si non, Entra ID est mort, quel que soit le prix. À vérifier dans le portail.
2. La sortie réseau de la salle laisse-t-elle passer login.microsoftonline.com ? curl -sI https://login.microsoftonline.com depuis le serveur.
3. Les utilisateurs applicatifs sont-ils des comptes du tenant de l'école, ou des comptes externes ? Ces deux cas ne relèvent pas de la même offre Entra, ni de la même tarification.
4. Le coût vient après ces trois questions, pas avant.

Objection de fond, à porter en séance. Entra ID crée exactement la dépendance que le groupe a rejetée dix minutes plus tôt pour les secrets. Si l'authentification passe par Azure, une coupure réseau en salle empêche toute connexion, y compris pendant la démonstration du J10. Le raisonnement appliqué au Vault s'applique mot pour mot à l'authentification, et le groupe ne l'a pas vu.

2.2 Stockage — tranché depuis, voir §1 bis

Décision : médaillon complet dans le data lake, PostgreSQL conservé pour l'applicatif et pour servir la zone or. Ce qui suit est le compte rendu de la séance.

C'est le sujet qui a occupé le plus de temps et il se termine dans le flou.

Le groupe a envisagé de supprimer PostgreSQL : « techniquement, à part l'authentification, si on met tout dans le data lake, ça ne sert à rien ». La position inverse a été défendue dans la foulée, avec l'argument du coût d'interrogation : « si ça reste dans le data lake, c'est hyper lourd d'interroger tout le temps ».

Une architecture en médaillon (bronze, argent, or) a été décrite en séance. La position qui semble l'emporter en fin de discussion est : données brutes et traitements en PostgreSQL + TimescaleDB, stockage objet réservé aux modèles entraînés. Elle n'a jamais été formulée comme une décision.

Ce qui manque pour trancher :

• Que contient exactement le data lake : les lectures brutes, ou seulement les artefacts de modèle ? Les deux réponses ont été données par des personnes différentes.
• Prometheus et Grafana peuvent-ils lire un data lake ? La question a été posée et la réponse a été « oui je crois, de mémoire, à revérifier ». Elle n'a pas été revérifiée. Si la réponse est non, l'architecture de supervision change.
• Où vit la base de MLflow, et où vivent ses artefacts ?

Attention. « À part l'authentification, PostgreSQL ne sert à rien » est faux et cette phrase a orienté toute la discussion. La base porte les lectures brutes avec leur data_quality, la série reconstituée et sa méthode d'imputation, l'historique des alertes, l'état des capteurs, les prévisions avec la version du modèle qui les a produites, et les recommandations avec leur règle. Les comptes utilisateurs sont une table sur sept. Même avec Entra ID, il faut une table locale associant l'identifiant Entra à un rôle et à des sites, parce que l'autorisation par ressource ne peut pas être déléguée à un fournisseur d'identité qui ignore vos sites.

2.3 Cloisonnement multi-client

Le sujet a été soulevé : « il ne faut pas qu'une entreprise puisse accéder aux données d'une autre ». Une piste a été évoquée, un data lake par client, sans conclusion.

Ce qui manque : le projet livre-t-il un seul client modélisé, ou plusieurs ? Le cloisonnement passe-t-il par un identifiant de client sur les tables et un filtrage à l'API, ou par une séparation physique du stockage ? La deuxième option est hors budget de temps.

2.4 Infrastructure en code

Deux affirmations contradictoires dans la même réunion :

• « Terraform, pas prioritaire », « ça c'est à toute fin »
• puis, quelques minutes plus tard : « dans ce cas-là on est obligé d'avoir Terraform »

Ansible a été qualifié d'optionnel : « comme ça si jamais tu as besoin de mettre plusieurs on-premise, de dupliquer les serveurs. Mais ça c'est optionnel. »

Ce qui manque : EC04 est notée sur un IaC fonctionnel et EC03 sur un pipeline complet. Repousser Terraform « à la fin » revient à repousser une épreuve notée. Il faut décider si Ansible est le déploiement local officiel, ou si c'est la chaîne d'intégration qui déploie. Les deux à la fois donnent deux chemins de déploiement dont aucun ne fait autorité.

2.5 Chaîne d'intégration, contenu exact

Évoqués sans être arrêtés :

• Un équivalent de SonarQube. Le nom n'a pas été retrouvé en séance.
• Trivy et un scan OWASP, mentionnés comme une pipeline indépendante.
• Une pipeline de réentraînement du modèle : la question a été posée puis abandonnée sans réponse.
• Ce qui bloque une fusion n'a pas été défini : pipeline verte ? analyse statique ? seuil de couverture ?

2.6 Notifications et outillage

• Un canal de notification pour les alertes Grafana et les demandes de fusion. Un webhook Teams a été envisagé, la faisabilité dans les groupes Teams n'est pas connue : « je pense qu'on peut ».
• SOPS et age pour versionner les secrets chiffrés dans le dépôt. Mentionné, mal compris en séance, à documenter.
• Une pipeline qui appellerait Claude pour générer un wiki à chaque fusion et préparer le point du matin. Idée intéressante, non décidée, et il faut vérifier qu'elle est compatible avec les règles de l'épreuve.
• VPN Forti nécessaire pour travailler à distance, à demander pour ceux qui ne l'ont pas.

2.7 Répartition des tâches

La répartition a démarré en toute fin de réunion et a été coupée par l'heure. Seuls deux engagements sont audibles : les tickets et le modèle de demande de fusion pour l'un, la chaîne d'intégration pour un autre. Rien n'est écrit.

---

3. Points bloquants

Classés par urgence. Les trois premiers ne sont pas apparus en réunion.

3.1 Le miroir du dépôt n'existe pas — bloquant, aujourd'hui

Le cadrage impose de pousser le code « sur un dépôt distant ». La forge Forgejo est hébergée sur le serveur de travail : ce n'est pas un dépôt distant, c'est le même point de défaillance. Tant que le miroir sortant n'existe pas, la règle n'est pas respectée et une perte du conteneur efface le travail des six.

C'est écrit dans ADR-005 comme devant être fait le premier jour. La réunion n'en a pas parlé.

3.2 Le port 443 est déjà occupé — bloquant dès le premier déploiement

Caddy tourne déjà sur le serveur pour la forge et écoute 0.0.0.0:443. Le groupe vient de choisir Caddy comme proxy applicatif. Deux instances ne peuvent pas se partager le port.

Aggravant : le conteneur LXC non privilégié interdit tout réseau Docker, toute la pile tourne en network_mode: host. Les sept à dix conteneurs applicatifs vont donc se disputer des ports sur une interface unique, en plus des 443, 2222 et 22 déjà pris.

Il faut un plan d'adressage de ports écrit avant que quiconque déploie. Le plus simple est un Caddy unique, celui de la forge, avec un bloc par service et un propriétaire unique du Caddyfile.

3.3 « La pipeline ETL les filtre déjà » — contresens sur le sujet

Phrase entendue au sujet des valeurs nulles. Le cadrage dit l'inverse, explicitement :

« Des valeurs null apparaissent volontairement (panne capteur, perte réseau). Ne les filtrez pas — stockez-les avec leur data_quality, ça fait partie du test. »

Filtrer à l'ETL supprime la matière de la traçabilité, et donc de la restitution attendue en EC05. Il faut une règle d'imputation commune, écrite avant le code : quelle méthode pour combien de points manquants, à partir de quand on s'abstient, et où la méthode employée est inscrite à côté de la valeur.

3.4 Le sens du flux entre le local et le cloud n'est pas défini

Ce qui a été acté est « l'entraînement et la sauvegarde sur le cloud, le reste en local ». Ce n'est pas encore une topologie. Si l'entraînement s'exécute chez Azure, il doit lire les données, qui sont en salle sur un réseau privé non routable. Soit la salle pousse en continu, et alors la donnée brute sort, soit le cloud tire, et il faut un accès entrant que personne ne peut ouvrir.

À noter : un Tesla T4 de 15 Go est disponible et inutilisé sur le serveur. Personne dans la réunion ne le sait. Il rend l'argument « l'entraînement doit aller dans le cloud » beaucoup plus difficile à défendre. Attention toutefois, la carte est partagée sans cloisonnement entre les cinq groupes et MIG n'existe pas sur ce modèle : un entraînement lourd prive les autres groupes, avec une erreur incompréhensible pour eux.

Proposition, en attente d'arbitrage. L'entraînement s'exécute en local sur le T4, et l'inférence reste locale elle aussi, parce que prédire demande les mesures récentes en entrée et que ces mesures sont en salle. Servir le modèle depuis Azure obligerait à expédier ces variables à chaque prédiction, ce qui reproduit le problème de topologie, ajoute de la latence et fait sauter la cible de 200 ms.

Azure garde alors un rôle de durabilité seulement : artefacts de modèles, archive quotidienne agrégée, empreinte chiffrée de la base, état Terraform, budget et alerte, identité applicative. Rien en salle ne dépend d'Azure pour fonctionner, ce qui est exactement le principe que le groupe a appliqué en refusant le Vault dans le cloud.

3.5 Vue.js et la détention des jetons

Une application monopage Vue n'a pas de couche serveur : le jeton finit dans le navigateur, donc exposé à toute injection de script. Il faut trancher entre Nuxt (Vue avec rendu serveur, le jeton reste côté serveur) et Vue avec un mandataire d'API dans FastAPI qui pose un cookie httpOnly. La question devient plus aiguë si l'authentification passe par Entra ID : client public avec PKCE dans le navigateur, ou client confidentiel côté serveur ?

---

4. Sujets jamais abordés, et exigés par le cadrage

• Convention de nommage EADL_2026_NANTES_G2, imposée pour les machines et les branches Git.
• Sauvegarde et restauration : perte maximale acceptée, délai de remise en service, et une restauration réellement jouée une fois.
• Plafond de dépense Azure et son alerte, avant le premier déploiement. Qui possède l'abonnement ?
• Gestion des secrets au-delà de l'évocation de SOPS : où vivent les valeurs de production, comment la chaîne y accède.
• Stratégie de tests et couverture visée, alors que les pratiques TDD sont une compétence évaluée et qu'EC03 est notée dessus.
• Répartition des livrables du J10 : qui rend EC03, EC04, EC05, EC06, au format Markdown sur Teams à 9h00.
• Accès au serveur : aujourd'hui un compte root partagé à mot de passe trivial. Aucune action n'est imputable à une personne, alors que l'évaluation recueille des preuves individuelles quotidiennes.

---

5. Écarts avec le dossier de conception EC01 v2.0

Le dossier est déposé. Ces écarts ne sont pas des erreurs, mais ils doivent être tracés comme des révisions plutôt que subis : la qualité des revues de conception est un critère noté, et une décision révisée avec son motif vaut mieux qu'une incohérence découverte par le jury.

Dossier v2.0	Décision collective	À faire
Next.js 15, la couche serveur détient les jetons (ENF-01)	Vue.js	Mandataire FastAPI ou Nuxt, à arbitrer puis tracer
Jeton émis par l'API, fournisseur d'identité externe écarté	Keycloak auto-hébergé	Écart réel mais faible : Keycloak reste local, la propriété d'indépendance au cloud est préservée. À tracer en ADR
Référentiel unique, entrepôt en zones écarté (ADR-02 v2)	Médaillon bronze, argent, or	Écart le plus lourd. Ton ADR-02 v2 chiffrait le gain de la suppression à 4 jours-homme. À reprendre en ADR-02 v3, avec la zone or matérialisée en base comme mesure de compensation
Le cloud ne reçoit que des dérivés, ne déclenche rien (ADR-01 v3)	Entraînement dans le cloud	Définir le sens du flux, §3.4
Deux réseaux Docker dont un interne sans route sortante	Impossible sur ce LXC	Cloisonnement par adresse d'écoute, déjà en place sur la forge
Registre de modèles, repli en fichier versionné	MLflow	Cohérent, MLflow est d'ailleurs nommé dans les critères EC06
Déploiement par clé SSH restreinte depuis la chaîne	Ansible évoqué	Choisir un seul chemin de déploiement

---

6. À faire aujourd'hui

1. Configurer le miroir sortant du dépôt et pousser une fois. C'est la seule action dont l'absence peut coûter le projet entier.
2. ss -lntp | grep -E ':(443|3000|2222)' sur le serveur, puis écrire le plan de ports.
3. Vérifier dans le portail Azure le droit de créer une app registration, et tester la sortie réseau vers login.microsoftonline.com. Ces deux réponses ferment le débat d'authentification.
4. Écrire la règle d'imputation des valeurs nulles, avant la première ligne d'ETL.
5. Annoncer le Tesla T4 dans le canal du groupe, et la règle de courtoisie entre groupes.
6. Reprendre la répartition des tâches, coupée par l'heure, et l'écrire.

---

7. Suggestion sur la règle de relecture

La règle retenue, Tech Lead plus un relecteur tiré au sort, a été motivée en séance par le fait que tout le monde doit connaître le projet. L'intention est bonne, mais elle a deux effets à surveiller sur neuf jours.

D'une part, la présence obligatoire du Tech Lead sur chaque demande de fusion en fait un goulot d'étranglement, alors qu'il porte déjà la charge d'infrastructure. D'autre part, un Tech Lead qui passe son temps à relire produit peu de commits en propre, et l'oral EC02 du J10 vérifie précisément la cohérence entre le discours individuel et l'historique Git.

Piste : un relecteur obligatoire tiré au sort, et le Tech Lead obligatoire uniquement sur les chemins sensibles, infrastructure, chaîne d'intégration et sécurité, déclaré dans un fichier de propriétaires de code plutôt que dans une consigne orale.

---

Annexe A. Deux questions à poser à l'équipe

Rédigées pour être lues telles quelles, sans supposer que tout le monde connaisse les outils.

A.1 D'où le tableau de bord tire-t-il ses chiffres ?

On avait laissé un point en « à revérifier » hier : est-ce que Grafana et Prometheus peuvent lire directement dans le data lake ? J'ai vérifié, et la réponse est non pour les deux. Autant le savoir avant de commencer.

Prometheus ne sait pas lire un stockage de fichiers. Il marche dans l'autre sens : c'est lui qui va interroger nos services toutes les quelques secondes pour récupérer des chiffres techniques, temps de réponse, mémoire, est-ce que la collecte tourne. Il range ça chez lui. Nos mesures de consommation ne sont pas des chiffres de ce type, ce sont des données métier, elles ne passeront jamais par Prometheus.

Grafana sait afficher beaucoup de sources, mais il n'existe pas de bouton « MinIO ». Pour tracer une courbe à partir de fichiers dans le lac, il faut installer un moteur de requête entre les deux, du type DuckDB ou Trino. C'est un conteneur de plus sur un serveur qui en portera déjà une dizaine, et personne dans l'équipe ne l'a déjà fait tourner.

D'où la question : d'où viennent les chiffres affichés dans le tableau de bord ?

Option A, celle que je propose. Grafana lit PostgreSQL. Le lac garde l'historique complet et les modèles, et on y recopie en continu la version propre et à jour des données vers PostgreSQL, qui est la base que l'API et le tableau de bord interrogent. Grafana lit PostgreSQL nativement, sans rien installer, et on tient la cible de temps de réponse.

Option B. On ajoute un moteur de requête entre MinIO et Grafana pour tout garder dans le lac. C'est faisable, mais c'est un composant de plus à installer, configurer, documenter et maintenir, sur neuf jours.

Dans les deux cas MinIO reste, et le médaillon reste. La question porte seulement sur ce que le tableau de bord interroge.

A.2 EC03 à EC06 : un livrable par groupe, ou un par personne ?

Ce qui est clair : la note est individuelle. EADL - 05 - Modalités Évaluation, page 3, lignes 3 et 4 : « Ces épreuves sont évaluées sur la base de ce qui est déployé et fonctionnel le jour de la démo (J10 matin), complété par un entretien individuel. » Et page 1, ligne 7 : « Une partie des épreuves est collective, toutes les soutenances orales sont individuelles. » Le tableau de la page 1 porte « Individuel » en colonne Mode pour les quatre épreuves, et EADL - 01 - Sujet Officiel les intitule « EC03 — CI/CD (individuel) », « EC04 — Cloud (individuel) », et ainsi de suite.

Le « Collectif » du kickoff, diapositive 13, qualifie donc le mode de travail, et le « Individuel » des modalités qualifie le mode de notation. Les deux documents ne se contredisent pas, ils décrivent deux choses différentes.

Ce qui reste ouvert : le nombre de livrables. Un seul pipeline, un seul déploiement, un seul tableau de bord pour le groupe, avec des notes différenciées par l'entretien ? Ou un livrable par personne ? Aucun document ne le dit.

La conséquence pour nous ne dépend pas de la réponse. Personne ne peut défendre à son entretien une brique qu'il n'a jamais touchée. Si l'entretien porte sur l'ensemble du livrable, il faut que les six aient mis les mains dans la chaîne d'intégration et dans le déploiement, ce qui rejoint la règle « pas de silo, les rôles organisent le travail, ils ne cloisonnent pas les compétences ».

Question posée au formateur, texte prêt dans QUESTION-EC03-EC06-teams.txt. En attendant la réponse, on répartit en supposant que chacun devra pouvoir parler de tout.