Quel était l’objectif du sprint ?

• Objectif du sprint Automatiser et sécuriser le passage d’une compétition vers la phase opérationnelle, en déclenchant automatiquement la génération d’une fiche opérationnelle dès la clôture des inscriptions.
• Problème produit adressé Le passage entre la phase d’inscription et la phase opérationnelle reposait sur des actions manuelles, avec un risque d’oubli, d’erreur humaine et de manque de traçabilité. L’enjeu était de fiabiliser cette transition critique.

Qu’est-ce qui a été réellement réalisé ?

• Mise en place d’un scénario Make déclenché par le changement de statut d’une compétition
• Génération automatique d’une fiche opérationnelle dans Notion à partir des données de la compétition
• Ajout de conditions métier de déclenchement (date renseignée, nombre minimum d’équipes, validation complète)
• Mise en place d’un mécanisme de verrouillage via le champ Phase opérationnelle pour éviter les générations multiples
• Gestion des doublons (protection contre des changements de statut successifs)
• Envoi d’une notification interne avec lien direct vers la fiche générée

Quelles décisions importantes ont été prises ?

• Gouvernance métier : la clôture des inscriptions reste une action volontaire (décision humaine), l’automatisation ne fait que réagir à ce choix
• Architecture : Airtable reste le socle de données, Make orchestre les règles et Notion héberge la fiche opérationnelle
• Sécurisation : adoption d’un verrou logique unique via Phase opérationnelle pour empêcher toute régénération
• Séparation des responsabilités : logique métier dans Airtable, orchestration et gestion d’erreurs dans Make

Quels arbitrages ont été effectués ?

• Personnalisation des emails volontairement limitée pour prioriser la fiabilité du flux principal
• Validation et enrichissements avancés de la fiche repoussés au profit d’une première version robuste et traçable

Quels problèmes ou blocages ont été rencontrés ?

• Risques de doublons lors de modifications successives du statut (nécessité de filtres et verrous)
• Filtrage et ciblage des contacts internes pour la notification
• Perte de champs lors du passage par un Aggregator (ajustements du scénario et contrôles)

Quels risques ou points de vigilance pour la suite ?

• Risque de boucle ou de comportements inattendus si les champs de verrouillage (ou les vues techniques) sont modifiés
• Dépendance forte à la qualité des données amont (statuts et prérequis)
• Importance de ne pas modifier les vues/conditions utilisées par les automatisations sans validation technique

Quels items du backlog ont été impactés ?

• Automatisation de génération de fiche opérationnelle
• Notification interne liée au passage en phase opérationnelle
• Sécurisation du flux via verrou Phase opérationnelle
• Documentation associée (déclenchement, verrouillage, gestion d’incidents)
• Documentation RGPD liée aux données manipulées

Quels sont les objectifs du sprint suivant ?

• Formaliser un Design System simple pour assurer la cohérence visuelle
• Structurer et documenter les choix UI
• Mettre à jour les éléments de pilotage (Roadmap, Sprint Review)
• Consolider la présentation globale du système et des flux clés