La même date de lancement apparaît dans un brief Drive, une checklist Notion, un fil Slack et un jalon Linear. Votre recherche interne peut retrouver les quatre. Elle ne peut pas décider lequel fait foi sans une règle de gestion.
La « source unique de vérité » recherchée par les équipes n’est donc pas forcément un outil unique. Une PME peut avoir plusieurs sources faisant autorité : une par type d’information ou processus. Conservez l’original là où il est maintenu, puis indexez ou liez le contexte. Ne copiez qu’avec une raison, une provenance et une règle d’expiration ou de réconciliation.
Cet article propose une méthode de décision, pas un classement universel des outils ni un résultat de migration IZZY. Vos processus, permissions, forfaits et obligations de conservation exigent une revue propre à votre organisation.
La réponse en 60 secondes
- L’autorité est un rôle de gestion, pas une fonction logicielle.
- Pour chaque type de fiche, choisissez : conserver, indexer, lier, copier ou exclure.
- Désignez une source maintenue qui tranche les conflits.
- Donnez aux intégrations une identité stable, des droits et une règle de fraîcheur.
- Écrivez dans le système faisant autorité, puis enregistrez le résultat.
- Arrêtez de créer de nouveaux doublons avant de migrer les anciens.
Dans cet article
- Une source unique de vérité est une règle, pas un logiciel
- Choisir l’une des cinq actions de placement
- Attribuer un rôle conditionnel à chaque outil
- Donner un contrat opérationnel à chaque source
- Répartir un lancement produit dans cinq systèmes
- Réparer un conflit de propriété
- Migrer sans tout déplacer d’un coup
- Appliquer le test de gouvernance en cinq questions
1. Une source unique de vérité est une règle, pas un logiciel
IBM distingue le système qui maintient les données faisant autorité pour un domaine d’une vue qui rapproche plusieurs sources. Le vocabulaire varie, mais la décision reste concrète : où la fiche est-elle créée, qui la maintient et quelle version tranche un conflit ?
« Nous regardons d’abord Slack » est une habitude. « La responsable lancement maintient la date approuvée dans la fiche de contrôle Notion » est une règle. Acheter un moteur de recherche ou créer un espace Notion maître ne remplace pas cette attribution.
La définition NIST de l’architecture d’entreprise inclut la configuration, l’intégration et l’exploitation des systèmes ainsi que leurs relations avec la sécurité et la mission. Pour une PME, une cartographie d’une page peut suffire pour commencer. L’enjeu n’est pas de lancer un programme lourd, mais d’empêcher deux outils de gouverner le même champ.
2. Choisir l’une des cinq actions de placement
Attribuez une action principale à chaque type de fiche :
| Action | Signification | Exemple |
|---|---|---|
| Conserver | Maintenir l’original dans son système natif | Brief signé dans Drive |
| Indexer | Rendre le contenu autorisé interrogeable sans lui donner une nouvelle autorité | Texte du brief dans un index |
| Lier | Pointer vers la fiche native actuelle | Page Notion liée au projet Linear |
| Copier | Stocker un instantané justifié | Conditions approuvées jointes à la livraison |
| Exclure | Maintenir volontairement le contenu hors de la mémoire | Secret ou contenu privé non pris en charge |
Liez lorsque la personne peut atteindre la source actuelle. Indexez lorsque la recherche transversale exige le contenu. Une copie peut dériver : imposez source_id, URL ou version source, date de copie, finalité, responsable et expiration ou réconciliation.
« Copier pour gagner du temps » ne suffit pas. Si personne ne sait quelle copie peut être modifiée, vous avez créé une nouvelle concurrence d’autorité.
3. Attribuer un rôle conditionnel à chaque outil
| Outil | Peut faire autorité lorsque… | Préférer index/lien lorsque… | Ne pas supposer |
|---|---|---|---|
| Drive | Un fichier gouverné y est validé et maintenu | Un autre outil a besoin de contexte | Tout fichier est approuvé |
| Notion | Une fiche opérationnelle structurée y est maintenue | La page agrège des fiches détenues ailleurs | La recherche crée l’autorité |
| Slack | L’organisation gouverne volontairement la conversation | Le fil sert de contexte à une décision durable | Le chat est toujours temporaire |
| GitHub | Le travail dépend du dépôt : code, PR, ticket, release | L’approbation est commerciale ou transverse | Tout travail technique lui appartient |
| Linear | L’équipe y maintient propriétaires, états et livraison | La fiche est documentaire ou propre au code | Toutes les PME doivent l’utiliser ainsi |
Google indique que les fichiers d’un Drive partagé appartiennent à l’équipe, sous réserve de l’édition et des règles internes. Notion peut interroger des sources de données structurées, mais sa recherche API n’est pas exhaustive. GitHub prend en charge les tickets. Les tickets Linear appartiennent à une équipe. Ces capacités rendent un rôle possible ; votre processus l’attribue.
Slack exige une décision explicite. La recherche existe, la conservation est configurable et les messages peuvent être modifiés ou supprimés. Décidez si un fil constitue une preuve gouvernée ou si la décision doit être promue dans une fiche maintenue.
4. Donner un contrat opérationnel à chaque source
Pour chaque type de fiche faisant autorité, indiquez :
- identifiant natif et identifiant transverse ;
- créateur, responsable de maintenance et arbitre des conflits ;
- lecteurs, auteurs et champs gouvernés ;
- date de mise à jour et fraîcheur requise ;
- index, liens et copies en aval ;
- règles d’écriture, de réconciliation et de retrait.
Utilisez des identifiants natifs stables plutôt que des titres modifiables. Dans Linear, déplacer un ticket entre équipes peut changer son identifiant lisible et son URL, tandis que les anciennes URL redirigent. Une intégration doit connaître ce comportement.
La fraîcheur est un contrat, pas une case « webhook activé ». Les notifications Drive demandent au consommateur de lire le journal des modifications. GitHub et Linear documentent des webhooks, mais la livraison d’un événement ne prouve pas la réussite de la mise à jour en aval.
Conservez source_updated_at, event_received_at, downstream_updated_at et sync_state. Si l’index ou la copie est en retard, affichez-le au lieu de la présenter comme actuelle.
Écrivez dans la source faisant autorité lorsque c’est possible. Après une écriture validée, enregistrez l’identifiant natif, l’URL, le résultat et l’heure - la même discipline que celle qui évite les tickets en double issus des notes de réunion. Si un autre système doit modifier un champ, précisez la direction - Linear → Notion - plutôt que « synchronisation bidirectionnelle ».
Pour les données personnelles, la CNIL recommande de limiter la collecte au nécessaire, de gérer les habilitations et de fixer des durées de conservation. Ces repères bornent la copie et l’indexation ; ils ne prouvent pas la conformité de votre architecture.
5. Répartir un lancement produit dans cinq systèmes
Prenons le lancement Atlas :
| Fiche | Système faisant autorité | Autre placement |
|---|---|---|
| Brief approuvé et critères d’acceptation | Drive | Indexé ; lié depuis Notion |
| Page de contrôle et journal de décisions | Notion | Liens vers les fiches natives |
| Discussion tarifaire | Slack | Indexée comme contexte ; décision promue |
| Branche, PR et correctif de sécurité | GitHub | État lié au contrôle du lancement |
| Travail, responsables et jalon | Linear | Synthèse liée au contrôle |
Il n’existe pas forcément une fiche de lancement universelle. « Qu’avons-nous approuvé ? » peut renvoyer à Drive ou Notion selon la règle. « Le correctif est-il fusionné ? » renvoie à GitHub. « Qui porte le travail restant ? » renvoie à Linear.
La mémoire opérationnelle rapproche les cinq sans effacer leurs rôles. La page Notion peut coordonner la vue ; elle ne doit pas copier cinq dates modifiables. Pour approfondir le rôle d’une page de contrôle, voir le guide IZZY sur l’organisation du contenu dans une petite équipe.
6. Réparer un conflit de propriété
Supposons que Drive indique le 14 octobre, Notion le 21 et Linear le 18.
- Suspendez la propagation automatique de ce champ.
- Rassemblez valeur, identifiant source, auteur et date de chaque version.
- Appliquez la règle de conflit ou sollicitez l’arbitre nommé.
- Actualisez la source faisant autorité par son circuit normal.
- Remplacez les copies modifiables par des liens ou projections contrôlées.
- Enregistrez la résolution et testez la mise à jour suivante.
Ne choisissez pas la date la plus récente sauf si la règle le prévoit. Un message Slack récent peut rester une proposition non validée.
Rendez visibles les états conflict, partial_write, denied et replay_required. L’acheminement d’erreurs et la détection de doublons peuvent aider ; ils ne décident pas quelle valeur métier gagne.
7. Migrer sans tout déplacer d’un coup
Commencez par les types de fiches, pas par les dossiers. Inventoriez quelques exemples à conséquence élevée : engagement client, prix, version contractuelle, validation de release, responsable d’incident ou échéance.
Ensuite, arrêtez de créer de nouveaux doublons. Modifiez modèles, automatisations et consignes afin que les nouvelles fiches utilisent l’autorité choisie. Déplacer l’historique pendant que les workflows produisent encore des versions parallèles ne résout rien.
Migrez une classe à la fois :
- Déclarez la cible et le responsable de transition.
- Ajoutez identifiants natifs et liens retour.
- Redirigez intégrations et recherche.
- Réconciliez les fiches actives.
- Marquez les anciennes copies en lecture seule, archivées ou remplacées.
- Testez droits, fraîcheur, conflit et retour arrière.
Ne supprimez pas les sources historiques pour embellir le schéma. Conservation, preuve et suppression nécessitent leur propre décision.
8. Appliquer le test de gouvernance en cinq questions
Avant d’intégrer un type de fiche à la mémoire opérationnelle, demandez :
- Où la fiche est-elle créée ?
- Qui répond de sa maintenance ?
- Quelle version tranche le conflit ?
- Comment les changements autorisés atteignent-ils index, liens ou copies ?
- Comment la fiche est-elle retirée ou remplacée ?
Si une réponse manque, marquez la classe unresolved et gardez l’automatisation en lecture seule. La recherche peut exposer des éléments, mais la réponse doit indiquer que l’autorité n’a pas pu être vérifiée.
Revoyez la carte lorsqu’un outil, une équipe, un workflow, un modèle d’accès ou une obligation change. Une règle documentée seulement au lancement dérivera aussi vite que les copies qu’elle devait contrôler.
Conclusion : une mémoire, plusieurs systèmes responsables
Une source unique de vérité n’exige pas une base unique. Elle exige une règle claire pour chaque type d’information.
Conservez l’autorité près des personnes qui la maintiennent. Indexez et liez pour retrouver. Copiez avec provenance et échéance. Excluez volontairement. Puis rendez observables identité, accès, fraîcheur, conflit et écriture.
Cartographions cinq fiches qui se contredisent
Apportez cinq fiches présentes dans plusieurs outils, leurs emplacements et un conflit non résolu. IZZY peut cartographier les autorités, les placements et les limites d’automatisation avant toute migration. La recommandation utile peut être de supprimer des intégrations, pas d’en ajouter.
C’est exactement le périmètre de notre service Automatisation IA n8n.
Questions fréquentes
Un système de référence maintient les données faisant autorité pour un domaine. Une vue consolidée peut rapprocher plusieurs systèmes, sans devenir leur lieu d’édition.
Seulement pour les fiches que l’équipe décide d’y créer et d’y maintenir. Notion peut aussi indexer ou coordonner des éléments détenus ailleurs.
Pas nécessairement. Conservation et modification sont configurables. Décidez si Slack conserve une preuve gouvernée ou si les décisions doivent être promues.
Non. Une copie justifiée doit préciser provenance, finalité, responsable, accès, fraîcheur et expiration ou réconciliation.
Choisissez une fiche à conséquence élevée qui se contredit déjà, nommez son responsable et son workflow, puis empêchez les nouveaux doublons.
Sources et méthode
Recherche vérifiée le 27 juillet 2026 dans les documentations officielles de Google, Notion, Slack, GitHub, Linear, n8n, IBM/NIST et la CNIL.
Cette adaptation est un guide d’architecture IZZY. Aucun modèle de données client, environnement, migration, synchronisation ou système de permissions n’a été testé. Exhaustivité, latence, sécurité, résultats, ROI et conformité restent non vérifiés.