Vendredi, le responsable du delivery, chef de projet ou responsable de compte nommé pour l’exécution et la communication client, rapproche Linear, GitHub, Slack et Notion. Le rapport de statut client part tard ou rassure malgré une preuve manquante.
Automatisez collecte, normalisation, classement et brouillon vérifiable. L’interprétation, la formulation client, l’approbation et l’envoi restent humains.
Cet article couvre l’assemblage du rapport et son approbation. Quel système fait autorité pour chaque fait relève de la partie 3 de ce guide ; transformer les notes de réunion en tâches suivies, en amont d’une bonne part de cette activité, est la partie 1. Le parcours complet est sur la page du guide.
La réponse en 60 secondes
- Collecter les signaux autorisés par période.
- Normaliser en préservant identité et lien natifs.
- Classer faits, changements, blocages, preuves manquantes.
- Rédiger un brouillon client avec ses incertitudes.
- Faire relire par le responsable du delivery le sens et les mots.
- Publier ou envoyer après approbation de la version et du canal exacts.
Signalez valeurs inconnues et faits manquants ; distinguez faits, interprétations et approbations.
Dans cet article
- Comprendre pourquoi l’activité devient un statut trompeur
- Donner un contrat de reporting à chaque source
- Collecter les signaux d’une période bornée
- Normaliser sans effacer la provenance
- Séparer l’activité de l’interprétation métier
- Rédiger le rapport avec ses preuves
- Faire valider par le responsable du delivery avant envoi
- Déployer sur un périmètre restreint et surveiller les écarts
1. Comprendre pourquoi l’activité devient un statut trompeur
Les outils enregistrent des événements. Le responsable du delivery les interprète selon le plan, les conditions d’acceptation et les engagements client.
Gardez cinq niveaux distincts :
- activité observable : événement enregistré ;
- avancement : écart au plan ;
- préparation : validations nommées ;
- impact client : effet étayé ;
- achèvement contractuel : conditions d’acceptation enregistrées.
Ticket (« issue ») fermé, proposition (« pull request ») fusionnée, fil Slack actif et page Notion modifiée restent des preuves à examiner, sans démontrer à eux seuls l’avancement, la préparation, l’impact client ou l’achèvement contractuel.
2. Donner un contrat de reporting à chaque source
La vue agrégée n’est pas une autorité. Bornez chaque système ; la règle d’autorité tranche.
| Rôle | Responsabilité | Préserver | Ne prouve pas | Décision humaine |
|---|---|---|---|---|
| Linear | Travail planifié | ID, état, date, lien | Livraison | Interpréter |
| GitHub | Changements | Dépôt, ID, date, lien | Déploiement/valeur | Interpréter |
| Slack | Conversation | Canal, fil, date, mutation | Décision approuvée | Trier le contexte |
| Notion | Décisions, rapports | Page, état, lien | Couverture/approbation | Arbitrer |
| n8n | Orchestration | Exécution, erreur, nouvelle tentative (« rejeu ») | Autorité d’envoi | Traiter l’échec |
| Responsable du delivery | Interpréter, approuver | Motif, correction, décision | Approbation implicite | Autoriser la remise |
Linear expose tickets, projets, jalons, cycles, workflows, statut projet, relations et commentaires : des entrées, pas des conclusions client. L’autorisation OAuth de Linear fixe l’identité technique et les permissions ; elle ne vaut pas approbation.
Les autorisations GitHub dépendent des points d’accès. Les périmètres OAuth (« scopes ») de Slack bornent l’accès, pas l’autorité. Une intégration Notion accède uniquement au contenu qui lui est explicitement partagé ; sa recherche retrouve par titre les pages et sources de données partagées, sans parcourir leur texte intégral ni couvrir tout l’espace de travail. Les connecteurs IA Notion situent le produit, sans prouver un environnement réel.
Pour les données personnelles, la CNIL demande une collecte limitée au nécessaire. Elle recommande des habilitations bornées, validées, revues et retirées. Ce n’est pas un constat de conformité.
3. Collecter les signaux d’une période bornée
Fixez la période et le fuseau ; conservez ID, URL, date et lacunes.
- Linear. La recherche a ses limites. L’API GraphQL peut renvoyer des erreurs ou des données partielles ; les notifications automatisées (« webhooks »), bornées et signées, peuvent être relancées selon leurs règles ou désactivées après échec.
- GitHub. Commits, propositions, tickets et versions sont distincts ; un ticket peut aussi être une proposition. Les filtres bornent les listes sans prouver leur complétude. L’inspection est limitée ; les échecs ne sont pas automatiquement relancés.
- Slack. Recherche, historique et fils dépendent du jeton, des droits, de la pagination et des limites. La conservation peut retirer l’historique. Une politique peut autoriser l’édition ou la suppression ; les événements de changement et suppression signalent une mutation, pas une correction métier.
- Notion. Les requêtes utilisent des filtres, des tris et une pagination bornée. Une page ne retourne pas tout son contenu ; les commentaires sont séparés et paginés.
- n8n. Un workflow publié peut utiliser Schedule Trigger ou Webhook. Les nœuds Linear, GitHub, Slack et Notion exposent des opérations définies, pas une couverture complète.
Accès incomplet, historique ou recherche limités, webhook en échec ou désactivé, et couverture réduite par conservation, pagination ou réponse partielle deviennent des preuves manquantes (missing) ou incertaines (uncertain), jamais « aucune activité ».
4. Normaliser sans effacer la provenance
Utilisez, dans cet ordre :
project_id, period, source_system, source_id, source_url, event_type, occurred_at, owner, fact, authority, confidence, client_visible, review_state.
Conservez le source_id natif ; signalez toute valeur inconnue. occurred_at n’est pas l’heure de collecte ; authority porte la règle de conflit ; confidence n’est jamais une approbation.
Merge et Edit Fields peuvent réunir, écraser ou écarter. Traitez les collisions et données non appariées : transformer n’est pas vérifier.
5. Séparer l’activité de l’interprétation métier
| Niveau | Exemple | Responsable | Limite |
|---|---|---|---|
| Fait sourcé | « La proposition 184 présente l’état de fusion observé » | Système source | Ni déploiement, ni valeur |
| Interprétation métier | « Le changement contribue au jalon, sous réserve des tests » | Responsable du delivery | Pas la formulation approuvée |
| Formulation client approuvée | Texte final pour une version et un canal | Responsable autorisé | Pas une autre version |
Préservez contradictions, suppressions, incertitudes et autorités non résolues. Le statut et les mises à jour Linear gardent un point de vue humain : l’activité ne décide ni de la santé ni du texte client.
6. Rédiger le rapport avec ses preuves
Le rapport d’avancement client (ou rapport de statut client) compte dix champs :
| Champ | Comportement requis |
|---|---|
period | Période couverte |
sourced_facts | ID, lien, date natifs |
changes | Écart à la référence |
blockers | Preuve, responsable |
decisions | Approuvées, pas seulement discutées |
risks | Appréciation humaine |
missing_evidence | Preuve absente/contradictoire |
next_steps | État, responsable |
owner | Responsable/inconnu |
approval_state | Brouillon, approuvé, rejeté, expiré |
Notion peut créer ou modifier une page avec les accès requis ; un brouillon matérialisé n’est pas approuvé. AI Transform peut produire du code en lecture seule sur n8n Cloud ; validez-le.
Semaine Atlas illustrative, pas un cas client IZZY.
| Étape | Action Atlas de référence | État de revue visible |
|---|---|---|
| Collecter | Récupérer les preuves autorisées | Accès, conservation, webhooks manquants |
| Normaliser | Associer les treize champs | Responsables, dates, conflits inconnus |
| Classer | Séparer faits et lacunes | Aucune conclusion de santé |
| Rédiger | Assembler les dix champs liés | Contradictions visibles |
| Revoir | Corriger sens et mots | Décision version/canal |
| Publier/envoyer | Rester fermé avant validation | Aucune approbation implicite |
7. Faire valider par le responsable du delivery avant envoi
Il vérifie la version, la période, la couverture, les lacunes, la formulation, les destinataires et le canal. Enregistrez l’approbateur, l’heure, l’état et l’expiration ; toute modification matérielle rouvre la revue.
Respond to Webhook répond sans autorité de publication. Send Email envoie ou attend. Les approbations Slack dans n8n enregistrent l’identité de la personne qui répond et peuvent restreindre les approbateurs ; si la liste est vide, toute personne voyant la demande peut répondre. Cette fonctionnalité en version préliminaire (« preview ») peut évoluer, fait l’objet d’un déploiement progressif, peut ne pas être disponible sur une instance et ne doit pas devenir une dépendance en production. L’autorité métier reste définie séparément. Les exemples de relais humain et de revue avant outil illustrent des mécanismes, pas un contrat client.
Pour les données personnelles, la CNIL recommande de tracer les opérations pertinentes sans duplication excessive ; la minimisation s’applique aussi aux journaux et à leur conservation.
Voir aussi IZZY sur les accès des agents IA, les contrôles avant autonomie et la gouvernance de la production.
8. Déployer sur un périmètre restreint et surveiller les écarts
| Étape | Comportement permis | Arrêter ou réduire si |
|---|---|---|
| Comparaison en parallèle | Lire une période ; ne pas envoyer | Autorité, couverture ou traçabilité insuffisante |
| Phase contrôlée | Préparer une version ; bloquer l’envoi | Version, approbateur ou canal invalide |
| Exécution récurrente limitée | Répéter sources, période et contrat | Source, schéma, canal ou responsable modifié |
Error Trigger et les vues d’exécution exposent des preuves d’échec bornées ; supprimer un workflow supprime son historique d’exécution.
Surveillez : échecs de collecte, données obsolètes, nouvelles tentatives, enregistrements non appariés, version, approbation et envois bloqués. Gardez une voie d’arrêt, sans seuil ni SLA inventé.
Conclusion : automatiser l’assemblage, pas le jugement client
Automatisez la collecte et le brouillon. Rendez visibles la provenance, les contradictions, les valeurs inconnues et l’approbation.
Atlas reste illustratif ; aucun résultat n’a été testé.
Cartographions votre reporting
Apportez six éléments : votre rapport actuel, les systèmes sources, les contrôles manuels, le responsable de l’approbation, le canal et un statut trompeur. IZZY cartographie les preuves, les interprétations et les approbations, puis borne un pilote. Standardiser d’abord le rapport ou les règles d’autorité peut être le bon résultat.
C’est exactement le périmètre de notre service Automatisation IA n8n.
Questions fréquentes
Il rassemble les preuves, prépare un brouillon et bloque l’envoi jusqu’à revue humaine, sans décider de la santé du projet.
Non. Interprétez leurs états selon le plan et les conditions d’acceptation.
Comme preuve bornée par une règle d’autorité ; le volume ne crée pas l’autorité.
Pas ici. Version et canal doivent être approuvés ; la fonction Slack préliminaire ne doit pas devenir une dépendance en production.
Signalez-la, bloquez la conclusion et alertez le responsable du delivery.
Sources et méthode
Recherche vérifiée le 28 juillet 2026, chaque lien revérifié le 7 septembre 2026, à partir de la documentation officielle actuelle de Linear, GitHub, Slack, Notion, n8n et de la CNIL. Les liens officiels accompagnent chaque affirmation produit. Le workflow, le schéma et le contrat d’approbation sont des recommandations IZZY.
Aucun environnement, identifiant, réponse API, webhook, exécution n8n, retour d’approbation, jeu Atlas, exactitude du rapport, résultat client, destinataire, CMS ou publication/envoi n’a été testé. La documentation peut changer après la date de vérification.