Dans une PME, le même brief apparaît trois fois. Une version supprimée ou désormais réservée à la direction alimente encore une réponse. La DSI et les opérations voient « synchronisé », mais pas où la mise à jour s’est arrêtée.
Un pipeline d’ingestion RAG fiable suit un cycle contrôlé : détecter, identifier, récupérer, analyser, découper, insérer ou mettre à jour (upsert), réconcilier et exposer l’état. Ses identités restent distinctes. Un webhook signale du travail, sans prouver la fraîcheur.
Cette partie traite ingestion et fraîcheur. Autorité, choix de solution et évaluation/ROI restent aux parties 3, 4 et 9 du guide. Aucun tenant, corpus, parseur, workflow, modèle d’accès, index ni résultat client n’a été testé.
La réponse en 60 secondes
Pour piloter un pipeline d’ingestion RAG :
- détectez le changement et gardez un checkpoint ;
- retrouvez l’identité stable ;
- récupérez la version actuelle que l’intégration peut lire ;
- analysez-la sous un contrat versionné ;
- découpez en morceaux traçables (
chunks) ; - effectuez un
upsertavec des clés maîtrisées ; - réconciliez droits, suppression et remplacement ;
- exposez fraîcheur, échec et reprise.
L’objectif est une réconciliation observable et sûre à rejouer, pas une livraison exactement une fois, une fraîcheur immédiate, une déduplication universelle ou des droits automatiquement corrects.
Dans cet article
- Détecter le changement à la source
- Résoudre une identité stable
- Récupérer la version actuelle autorisée
- Analyser et classer
- Découper en chunks avec les métadonnées source
- Effectuer un upsert idempotent
- Réconcilier suppression, droits et remplacement
- Exposer la fraîcheur et l’état d’échec
1. Détecter le changement à la source
Décision : quel signal, quel périmètre, quel checkpoint ?
Après l’inventaire, passez aux changements incrémentaux. Recherche paginée, journaux utilisateur ou Drive partagé, jetons et paramètres de Drive partagé ont des portées distinctes. La recherche peut être incomplète : notez périmètre, responsable et rattrapage.
Un webhook est un appel HTTP signalant un événement. Drive, Notion, Slack, GitHub et Linear diffèrent par renouvellement, ordre, reprise, charge utile et accès. Relisez l’état actuel.
Le rattrapage varie : la recherche Notion n’est ni exhaustive ni immédiate, l’historique Slack est paginé et soumis aux droits, et la pagination Linear n’est pas un journal immuable.
Scénario Drive partagé illustratif - pas un cas client IZZY. Six changements entrent ici : renommage, déplacement, révision, copie, droits, suppression. Un canal expiré place le brief en replay_required.
2. Résoudre une identité stable
Décision : quelle clé survit et relie les représentations ?
Un ID Drive reste stable malgré un renommage ou un changement de parent. Une copie a sa propre identité, même à contenu égal.
Notion sépare UUID de page, bloc et source de données. Slack utilise canal et horodatage. GitHub sépare livraison et chemin avec ref/SHA. L’UUID Linear identifie la livraison, pas l’objet.
| Identité | Sens contrôlé | Ne doit pas devenir |
|---|---|---|
| Fiche source | source_system + source_id | Nom, URL ou livraison |
| Document extrait | Version analysée | Autorité source |
chunk | Morceau relié à source/version | Vérité indépendante |
| Entrée d’index | Fiche reliée à chunk_id | ID universel |
| Champ exact | Sens minimal | Limite |
|---|---|---|
source_system | Fournisseur + connexion | Portée explicite |
source_id | ID natif | Pas un titre |
source_version | Version observée | unknown visible |
source_updated_at | Heure source | Pas l’index |
indexed_at | Écriture observée | Pas la visibilité |
permission_class | Référence d’ACL | Pas une garantie |
content_hash | Empreinte normalisée | Pas déduplication sémantique |
chunk_id | Clé du morceau | Liée à source/version |
sync_state | État explicite | Pas synced |
superseded_by | Remplacement | Pas automatique |
deleted_at | Heure de suppression | Trace de suppression (tombstone) séparée |
3. Récupérer la version actuelle autorisée
Décision : l’intégration peut-elle lire la bonne version ?
Drive utilise le téléchargement pour les blobs et l’export pour les documents Workspace. Le format et la taille bornent l’entrée du parseur.
Notion exige le partage actuel, une recherche bornée et le parcours des blocs. Slack dépend du type de jeton et des scopes. GitHub dépend du chemin, de la ref, du SHA, de la taille, d’URL temporaires et des permissions. Linear peut renvoyer HTTP 200 avec erreurs et données partielles.
Séparez récupération et analyse : denied signifie usage interdit ; partial, contenu incomplet. Un déplacement conserve source_id, mais impose de revoir les droits hérités.
4. Analyser et classer
Décision : la transformation est-elle complète sous ce contrat ?
Les blocs enfants et types non pris en charge Notion empêchent de déduire une extraction complète. Le Default Data Loader n8n charge binaire ou JSON, ajoute des métadonnées et relie un splitter ; il ne fournit ni identité, ni droits, ni assurance de parsing.
Versionnez parseur, classifieur et unités requises. Isolez l’incompatible en schema_parser_failure pour rejeu. Une section manquante reste partial.
5. Découper en chunks avec les métadonnées source
Décision : chaque morceau est-il traçable et retirable ?
Un chunk est un morceau adressable, pas un document faisant foi. Le splitter n8n expose taille et chevauchement sans créer identité ni complétude.
La carte des composants n8n sépare loaders, splitters, embeddings, magasins et retrievers sans fournir la reprise. Pinecone recommande des ID structurés et des métadonnées de source. Qdrant stocke un payload JSON fourni par l’application. Ces métadonnées peuvent filtrer ; elles ne prouvent pas l’application actuelle des droits source.
Si des données personnelles sont matériellement présentes, la CNIL recommande de limiter données et logs au nécessaire. Ce repère ne fixe ni finalité, ni base juridique, ni conformité.
Chaque chunk_id reste relié à la version ; les précédents attendent leur remplacement.
6. Effectuer un upsert idempotent
Décision : une reprise évite-t-elle une seconde représentation actuelle ?
Un upsert crée la fiche si la clé manque ou remplace celle portant la même clé. Idempotent signifie ici : rejouer vise le même état contrôlé, sans garantie exactement une fois.
Les surfaces diffèrent : n8n Pinecone documente la mise à jour par ID ; Qdrant, une autre surface. Aucune page ne représente toute l’API.
Remove Duplicates n8n compare des champs ou l’historique, pas le sens. L’upsert Pinecone écrase le même ID, pas ses chunks frères. Les points Qdrant ont des écritures, suppressions et conditions propres ; ils exigent réconciliation. Événements, lots ou double écriture avec réconciliation sont des options, pas des garanties.
Possédez les clés d’événement, source, version, chunk et magasin. Une copie de même empreinte reste candidate doublon. Liez remplacement et morceaux obsolètes.
7. Réconcilier suppression, droits et remplacement
Décision : quoi retirer, bloquer ou marquer remplacé ?
La ressource Drive expose corbeille, parent, version, permissions et capacités relatives à l’appelant ; le déplacement peut modifier les droits hérités. Dans Notion, la mise à la corbeille change in_trash sans suppression définitive par cet endpoint. Les événements de suppression Slack donnent canal et horodatage, sous les limites des scopes OAuth.
Le magasin est séparé : Pinecone supprime par ID, filtre ou namespace avec cohérence éventuelle. Qdrant supprime des points. L’acceptation ne prouve pas l’absence immédiate.
Dans Drive : renommage garde l’identité ; déplacement revoit les droits ; révision remplace les chunks ; copie signale un doublon ; perte d’accès donne denied. La mise à la corbeille signale l’état source. Le pipeline renseigne alors deleted_at, écrit un tombstone, trace empêchant le rejeu de ressusciter la version, puis vérifie le retrait aval.
Si des données personnelles sont concernées, la CNIL recommande de borner, retirer et revoir les habilitations. L’index réconcilie ces décisions sans prétendre les propager par défaut.
La durée dépend de la finalité et parfois d’obligations. Base active, éventuel archivage et effacement restent distincts. Aucune durée universelle ni conclusion juridique.
8. Exposer la fraîcheur et l’état d’échec
Décision : voit-on l’état actuel, l’échec et la reprise ?
L’historique GitHub est borné ; l’échec demande une relivraison. Les workflows d’erreur n8n se configurent ; visibilité et relance dépendent des accès. Rien ne remplace le checkpoint source.
sync_state | Preuve observée | Action du responsable | Condition de sortie |
|---|---|---|---|
duplicate | Clé/empreinte répétée | Classer ; réconcilier | Une version actuelle |
stale | Source en avance | Trouver ; rejouer | Preuve actuelle |
denied | Usage interdit | Bloquer ; isoler | Accès ou retrait confirmé |
deleted | Suppression observée | Tombstone ; retrait | Absence sans résurrection |
partial | Unités manquantes | Préserver ; isoler | Succès ou exclusion |
replay_required | Lacune ou échec | Rejouer le checkpoint | Checkpoint sans lacune |
schema_parser_failure | Parse impossible | Isoler ; versionner | Retraitement réussi |
Mesurez observation source, source_updated_at, checkpoint, traitement et indexed_at séparément. Fixez la fraîcheur par classe, sans SLA universel.
Le canal expiré laisse le brief en replay_required. Il redevient actuel après rattrapage seulement si version, droits, chunks et retrait aval sont réconciliés sans lacune. Ce n’est pas une preuve de qualité ou de valeur.
Conclusion : faire de l’état actuel un résultat étayé
Un pipeline d’ingestion RAG est un cycle contrôlé, pas un connecteur plus synced. Il exige identités liées, réconciliation et états visibles. Cette architecture n’a pas été testée.
Auditons une source et une classe de documents
Apportez une source, une classe de documents, le profil des changements, le modèle d’accès, l’attente de fraîcheur et un échec connu. IZZY bornera ce qui peut être observé, réconcilié et testé. La décision peut être « gouvernance de la source d’abord ».
C’est exactement le périmètre de notre service Automatisation IA n8n.
Questions fréquentes
Il détecte, identifie, récupère, analyse, découpe, effectue les upserts, réconcilie et expose l’état.
Non. L’empreinte signale l’égalité ; n8n compare des champs. Événement, source, document, chunk et index exigent des règles distinctes.
Non. Accès, récupération, analyse, indexation, réconciliation et preuve restent séparés.
Passez à denied, isolez, réconciliez, puis retraitez ou confirmez le retrait. Les droits Drive restent une entrée.
Enregistrez tombstone et deleted_at, utilisez la suppression fournisseur, bloquez le retour par rejeu et confirmez l’absence.
Sources et méthode
Recherche vérifiée le 27 juillet 2026 dans les documentations officielles Google Drive, Notion, Slack, GitHub, Linear, n8n, Pinecone et Qdrant, ainsi que les recommandations de la CNIL. Les liens officiels accompagnent chaque affirmation produit.
Cette adaptation est un guide d’architecture IZZY. Aucun tenant, webhook, parseur, workflow, index, propagation de droits, suppression, rejeu, résultat de recherche, SLA, résultat client ou conformité n’a été testé.