Process de livraison Telaria

Principe fondateur : aucun contact avec les devs sans spec complète. On applique strictement, on améliore par la pratique. "Increment is the key."

Ce process s'applique à toutes les instances de l'écosystème (Lead Tech Telaria, Lead Tech Adoption, Rédacteur web) pour toute livraison de fonctionnalité, correction ou évolution documentaire significative.

Nomenclature des environnements

Termes abandonnés : "preprod" (remplacé par dev ou staging selon le contexte).

Les 11 étapes

Règles absolues

• Brouillon spec validé par Mathieu avant envoi à Atlas — jamais en direct
• Atlas nomme toujours l'implémenteur dans son message à l'instance
• Ticket fermé = intouchable — bug ou évolution = nouveau ticket
• Chef n'intervient pas entre Atlas et l'instance une fois la spec transmise (sauf question remontée)
• L'instance ne touche pas au VPS prod de son propre chef — feu vert Chef obligatoire (étape 9)

Anti-patterns

Ces pratiques violent le process et doivent être signalées immédiatement au Chef :

• Spec sans validation Mathieu : Atlas reçoit un brouillon non validé et l'intègre quand même
• Brief sans spec : contacter un dev sans spec complète référencée
• Implémentation sans ref backlog : démarrer un travail sans ID TLR-XXX
• Livraison sans DoD : déployer sans avoir vérifié les critères de la spec
• Spec post-implémentation : écrire la spec après le code (elle ne peut plus être bloquante)
• Chantier parallèle non déclaré : démarrer un travail hors backlog sans accord Chef/Mathieu
• MEP sans staging : déployer en prod sans validation préalable sur staging (retex TLR-001, 2026-06-16)
• MEP sans feu vert : déployer en prod sans feu vert explicite Chef ou Mathieu
• Rouvrir un ticket fermé : tout changement post-done = nouveau ticket

Communication inter-instances — politique de rotation des inboxes

Les inboxes fichiers ont une taille limitée. Au-delà d'un certain volume, les instances risquent de rater des messages (scan tronqué).

Règle :

• Maximum 10 messages actifs par fichier inbox
• Au-delà : archiver les plus anciens dans inbox-from-<sender>.archive.md (append), conserver uniquement les 5 derniers dans le fichier actif
• Les instances consultent l'archive si elles recherchent un message ancien
• Cette règle s'applique à tous les canaux inbox de l'écosystème

Rôle d'Atlas dans ce process

Atlas intervient aux étapes 5 et 6 — intégration documentaire et transmission à l'implémenteur.

• Étape 5 : reçoit le brouillon du Chef (déjà validé par Mathieu), formate, intègre dans telaria-doc, committe. La spec est officielle dès ce commit. Si une question se pose → demande au Chef, jamais à Mathieu directement.
• Étape 6 : notifie l'instance implémenteur désignée par Chef ET notifie Chef en parallèle.
• Étape 11 : reçoit la notification de clôture du Chef, met à jour la doc si nécessaire.

Atlas ne pilote pas les étapes 7-10 — c'est le domaine du Chef, de Mathieu et de l'instance implémenteur.

Voir aussi

• Fiches de poste — responsabilités de chaque rôle
• Ecosystem — instances et canaux de communication
• Roadmap / Backlog — suivi des items TLR-XXX