Un lundi matin, la synchronisation hebdomadaire avec le SharePoint de la SGP se déclenche. 2 147 documents sont détectés : des bulletins de souscription, des pièces d'identité, des avis d'imposition, des RIB, des attestations diverses. Chaque document doit être lu par OCR, découpé en segments sémantiques, indexé dans la base vectorielle, et éventuellement analysé par un agent IA pour extraction et validation.
Si ces 2 147 traitements s'exécutent séquentiellement, un par un, il faudra plus de 36 heures. S'ils s'exécutent tous en même temps, le serveur sature et plus personne ne peut travailler. Le traitement en arrière-plan — ce que les développeurs appellent le background processing (exécution de tâches lourdes hors du flux principal de l'application) — est la solution à cette équation.
Pourquoi le traitement en arrière-plan est indispensable
Dans une application web classique, chaque action de l'utilisateur déclenche une requête HTTP. Le serveur la traite et renvoie une réponse. Ce modèle fonctionne pour afficher un formulaire ou enregistrer un champ texte. Il s'effondre quand le traitement prend 30 secondes, 2 minutes, ou 10 minutes.
Selon AIIM (Association for Intelligent Information Management, « State of the Intelligent Information Management Industry, 2025 »), le traitement OCR d'un document de 20 pages prend en moyenne 8 à 15 secondes avec un moteur performant. La génération d'embeddings (représentations vectorielles du texte utilisées pour la recherche par similarité) ajoute 2 à 5 secondes. Une extraction IA par agent ajoute 10 à 30 secondes selon la complexité du template.
Pour un dossier de souscription SCPI standard (12 documents, environ 80 pages au total), le traitement complet prend entre 2 et 4 minutes. Un utilisateur ne peut pas rester bloqué devant un écran de chargement pendant 4 minutes. Et une SGP ne peut pas demander à ses 15 gestionnaires de déclencher manuellement le traitement de chaque document, un par un.
La solution : déléguer les tâches lourdes à un système de traitement en arrière-plan qui les exécute de manière asynchrone (sans bloquer l'interface utilisateur) et les orchestre intelligemment.
L'architecture de la file de jobs dans Ragindeed
Ragindeed utilise un système de file de tâches qui fonctionne sur un principe simple : quand une tâche longue est détectée, elle n'est pas exécutée immédiatement. Elle est enregistrée dans une file d'attente avec toutes les informations nécessaires à son exécution future. Des processus dédiés piochent les tâches dans la file et les exécutent en arrière-plan.
Ce système diffère fondamentalement des architectures basées sur des files de messages externes ou sur les fonctions serverless (AWS Lambda, Azure Functions). Il est intégré directement dans la plateforme, ce qui offre plusieurs avantages décisifs pour la gestion documentaire :
- Transactionnalité : chaque job s'exécute dans une transaction de base de données. Si le traitement échoue à mi-parcours, tout est annulé proprement — pas de document traité à moitié.
- Visibilité : chaque job est un enregistrement consultable dans l'interface : statut, date de création, date d'exécution, durée, résultat, message d'erreur le cas échéant.
- Retry intelligent : en cas d'échec (timeout API, erreur réseau), le job est automatiquement reprogrammé avec un délai exponentiel (30s, 1min, 2min, 5min).
- Pas d'infrastructure supplémentaire : pas de serveur de files de messages à installer et maintenir. La base de données sert directement de file d'attente.
Les canaux : répartir la charge intelligemment
Toutes les tâches documentaires ne se valent pas. Un OCR consomme beaucoup de puissance de calcul. Une extraction IA consomme des tokens (et donc de l'argent). Une génération de représentations vectorielles consomme de la mémoire. Les exécuter toutes sur le même ensemble de processus serait inefficace et dangereux : une vague d'OCR pourrait bloquer toutes les extractions IA en cours.
Ragindeed résout ce problème par un système de canaux (channels)
Ragindeed résout ce problème par un système de canaux (channels) : chaque type de tâche est affecté à un canal dédié avec une capacité maximale configurable.
| Canal | Capacité | Rôle | Ressource critique |
|---|---|---|---|
| File OCR | 5 traitements parallèles | OCR des PDF scannés et complexes | CPU / appel API OCR |
| File indexation | 5 traitements parallèles | Génération des représentations vectorielles | Mémoire / appel API provider IA |
| File extraction IA | 10 traitements parallèles | Appels aux modèles de langage (extraction, classification, validation) | Tokens IA (coût) |
| File vision | 2 traitements parallèles | Extraction d'images de pages et représentations visuelles | CPU + stockage objet |
| File rapports | 3 traitements parallèles | Génération de rapports PDF/DOCX | CPU / mémoire |
| File conformité | 3 traitements parallèles | Vérifications LCB-FT (lutte contre le blanchiment et le financement du terrorisme) | Appels API externes |
| File transcription | 2 traitements parallèles | Transcription audio vers texte | CPU / appel API |
| File générale | 20 traitements parallèles | Tâches générales non catégorisées | Variable |
La capacité de chaque file est un choix d'architecture, pas un hasard. La file extraction IA a 10 traitements parallèles parce que les appels IA sont rapides (1-3 secondes chacun) mais fréquents (chaque extraction, chaque classification). La file vision n'en a que 2 parce que le traitement d'images est lourd en mémoire et que les coûts de représentations visuelles sont élevés. La file OCR a 5 traitements parallèles parce que l'OCR est le goulot d'étranglement du pipeline et qu'il faut suffisamment de parallélisme pour absorber les pics d'import.
Le pipeline de traitement : chaînage de jobs
Le traitement d'un document n'est pas une tâche unique. C'est une chaîne de tâches (pipeline) où chaque étape dépend de la précédente :
Document uploadé ou synchronisé
│
▼ [file OCR]
Étape 1 : OCR
Conversion en texte structuré (Markdown)
Découpage en segments sémantiques
│
▼ [file indexation]
Étape 2 : Indexation sémantique
Génération des vecteurs 1024 dimensions
Indexation dans la base de recherche vectorielle
│
▼ [file extraction IA]
Étape 3 : Extraction IA (si template configuré)
Application du template d'extraction structurée
Validation des champs extraits avec score de confiance
│
▼ [finalisé]
Étape 4 : Finalisation
Statut = terminé
Notification si nécessaire
En parallèle, si la vision documentaire est activée :
│
▼ [file vision]
Étape parallèle : Vision
Extraction des images de chaque page du PDF
Stockage sur le stockage objet sécurisé
Génération des représentations visuelles (1536 dimensions)
Ce chaînage est implémenté par un mécanisme de job chaining : à la fin de l'étape 1, le système crée automatiquement le job de l'étape 2 dans le canal approprié. Si l'étape 1 échoue, l'étape 2 n'est jamais créée — pas de traitement partiel incohérent.
Contrôle de concurrence : les verrous consultatifs
Quand 2 000 documents arrivent simultanément, un risque majeur apparaît : le traitement en double. Deux processus pourraient récupérer le même document et lancer l'OCR deux fois. Ou pire : deux processus pourraient tenter de créer les segments du même document en parallèle, générant des doublons dans la base de recherche vectorielle.
Ragindeed prévient ce problème par des verrous consultatifs — un mécanisme natif de la base de données qui permet à un processus de « réserver » une ressource sans bloquer les autres transactions. Avant de traiter un document, le processus tente d'acquérir un verrou sur l'identifiant du document. Si le verrou est déjà pris (un autre processus traite ce document), la tâche est reportée. Si le verrou est disponible, le processus le prend et commence le traitement.
Ce mécanisme est non-bloquant : les autres processus continuent de traiter d'autres documents pendant qu'un document spécifique est verrouillé. C'est la différence entre un feu rouge (qui arrête tout le trafic) et un système de réservation (qui empêche les conflits sans ralentir les autres).
Exemple concret : import de 2 000 documents depuis SharePoint
Revenons à notre scénario du lundi matin. Voici ce qui se passe réellement quand la synchronisation SharePoint détecte 2 147 nouveaux documents :
T+0 secondes — Le connecteur SharePoint crée 2 147 enregistrements de pièces jointes dans la base de données. Pour chaque document, une tâche OCR est enregistrée dans la file de traitement OCR.
T+1 seconde — Les 5 traitements parallèles de la file OCR commencent à piocher des tâches. Le premier document (un bulletin de souscription de 4 pages) est envoyé au moteur OCR.
T+12 secondes — Le premier document est traité par l'OCR. Six segments sémantiques sont créés. Une tâche d'indexation sémantique est automatiquement créée dans la file d'indexation. Les traitements OCR continuent avec les documents suivants.
T+15 secondes — La file d'indexation récupère la tâche. Les 6 segments sont convertis en vecteurs 1024 dimensions et indexés dans la base de recherche vectorielle. Si un template d'extraction est configuré, une tâche est créée dans la file d'extraction IA.
T+3 minutes — 75 documents sont entièrement traités (OCR + embedding). Les canaux fonctionnent en parallèle : pendant que l'OCR traite le document 76, les embeddings sont générés pour les documents 70-75, et l'extraction IA tourne sur les documents 60-69.
T+45 minutes — 1 000 documents traités. Le pipeline est en régime de croisière. La file OCR contient encore 1 147 tâches en attente, mais le débit est stable à ~22 documents par minute.
T+2 heures 30 — Les 2 147 documents sont entièrement traités. OCR, embeddings, et extractions finalisés. Les gestionnaires n'ont rien remarqué : l'interface est restée réactive pendant toute la durée du traitement.
Pendant tout ce temps, les utilisateurs continuent de travailler normalement : consultation de dossiers, saisie de souscriptions, génération de rapports. Le traitement en arrière-plan consomme les ressources serveur de manière maîtrisée, sans impacter l'expérience utilisateur.
Monitoring et observabilité
Un système de traitement en arrière-plan sans monitoring est une bombe à retardement. Ragindeed offre une visibilité complète sur l'état de la file de jobs :
- Tableau de bord en temps réel : nombre de jobs en attente, en cours, terminés, échoués, par canal et par période
- Alertes automatiques : notification si un canal accumule plus de X jobs en attente (signe de saturation) ou si le temps moyen de traitement dépasse un seuil
- Historique détaillé : chaque job conserve sa trace — heure de création, heure de début d'exécution, durée, résultat, message d'erreur
- Retry automatique : les jobs échoués sont reprogrammés avec un délai exponentiel. Après N tentatives infructueuses (configurable, par défaut 5), le job est marqué comme « échoué » et une alerte est générée
Pour une SGP soumise aux exigences de continuité d'activité de l'AMF (Autorité des marchés financiers, « Instruction AMF 2012-01 relative à l'organisation de la gestion des risques »), cette traçabilité est un atout : chaque document traité dispose d'un journal complet de son parcours dans le pipeline.
Comparatif avec les solutions concurrentes
| Critère | Ragindeed (file de tâches intégrée) | Files de messages externes | AWS Step Functions | Azure Durable Functions |
|---|---|---|---|---|
| Infrastructure requise | Aucune supplémentaire (la base de données suffit) | Serveur de messages à installer et maintenir | Compte AWS, configuration IAM, rôles | Compte Azure, App Service Plan |
| Transactionnalité | Oui (même transaction que les données métier) | Non (broker séparé de la BDD) | Non (orchestration externe) | Non (orchestration externe) |
| Visibilité des tâches | Interface intégrée, filtres par file/statut/date | Outils séparés à installer | Console AWS CloudWatch | Azure Monitor |
| Coût mensuel (2 000 docs/semaine) | Inclus dans la plateforme | ~50-100 EUR (serveur + infra) | ~80-200 EUR (transitions + Lambda) | ~60-150 EUR (Functions + storage) |
| Files dédiées | Oui, 8 files configurables | Oui (files distinctes) | Step machines distinctes | Orchestrations distinctes |
| Retry intelligent | Natif, délai exponentiel configurable | Natif | Natif (retry policies) | Natif (retry policies) |
| Souveraineté données | Hébergement Scaleway (France) | Dépend de l'hébergement choisi | AWS (régions EU disponibles, données transitent par API US) | Azure (régions EU, mêmes réserves) |
| Latence de dispatch | <100ms (même base de données) | ~50-200ms (via broker réseau) | ~200-500ms (API Gateway) | ~200-500ms (HTTP trigger) |
IDC (« Worldwide Intelligent Document Processing Forecast, 2025-2029 », février 2025) souligne que la latence de dispatch — le temps entre la détection d'un nouveau document et le début de son traitement — est un facteur critique pour les SGP qui traitent des souscriptions en temps réel. Les 100 millisecondes de Ragindeed, contre 200 à 500 millisecondes pour les architectures serverless, semblent négligeables pour un document, mais deviennent significatives multipliées par 2 000.
Gartner (« Market Guide for Intelligent Document Processing Solutions, 2025 ») note que les solutions IDP (Intelligent Document Processing — traitement intelligent de documents) qui intègrent nativement leur moteur de traitement asynchrone réduisent les coûts d'infrastructure de 30 à 45 % par rapport à celles qui reposent sur des services cloud tiers.
Dimensionnement et scalabilité
La capacité des canaux est configurable et ajustable à chaud, sans redémarrage, en fonction de la charge :
Profil « PME » (< 500 documents/semaine) :
Deux traitements OCR parallèles, deux traitements d'indexation, cinq traitements IA. Suffisant pour une SGP de 5-10 gestionnaires avec un flux documentaire modéré.
Profil « ETI » (500-5 000 documents/semaine) :
Cinq traitements OCR parallèles, cinq traitements d'indexation, dix traitements IA. Configuration standard de Ragindeed, adaptée aux SGP de taille moyenne gérant 10-20 SCPI.
Profil « Grande SGP » (> 5 000 documents/semaine) :
Dix traitements OCR parallèles, dix traitements d'indexation, vingt traitements IA. Pour les sociétés de gestion traitant des volumes importants, notamment en période de collecte trimestrielle.
McKinsey (« Operations of the future: How digital and AI are transforming asset management », 2025) estime que les SGP qui automatisent leur pipeline documentaire réduisent leurs coûts opérationnels de 25 à 40 %, avec un retour sur investissement moyen de 8 mois. L'ACPR (Autorité de contrôle prudentiel et de résolution), dans ses recommandations sur la transformation numérique des acteurs financiers (2024), encourage l'adoption de systèmes de traitement automatisé à condition qu'ils garantissent la traçabilité et la réversibilité des opérations — deux propriétés natives de l'architecture Ragindeed.
Tendances technologiques et projections
Architectures événementielles. Le modèle traditionnel du polling (vérifier régulièrement s'il y a du travail à faire) cède progressivement la place à des architectures event-driven (déclenchées par des événements en temps réel). Quand un document arrive, un événement est émis et déclenche instantanément le pipeline. Ragindeed combine les deux approches : synchronisation périodique (polling du connecteur de stockage) et traitement instantané (event-driven dès que le document est enregistré dans la base).
Traitement documentaire serverless. Forrester (« The Future of Document Processing Infrastructure, 2025 ») prévoit que 40 % des pipelines documentaires seront serverless d'ici 2027 — exécutés sur des fonctions éphémères facturées à l'usage plutôt que sur des serveurs permanents. L'avantage est l'élasticité (pas de serveur à dimensionner) ; l'inconvénient est la latence de démarrage à froid (cold start) et la perte de transactionnalité. Pour les secteurs réglementés comme la gestion d'actifs, l'approche intégrée de Ragindeed offre un meilleur compromis entre performance et conformité.
Edge computing pour l'OCR. AIIM anticipe l'émergence de l'OCR en périphérie (edge computing — traitement au plus près de la source de données) : un module OCR embarqué directement dans le navigateur ou sur le poste de travail, capable de prétraiter les documents avant leur envoi au serveur. Cette approche réduit la bande passante consommée et accélère le pipeline pour les documents simples (PDF natifs, images propres).
Orchestration par IA. Gartner (« Predicts 2026: AI Engineering », décembre 2025) prédit que d'ici 2028, les systèmes d'orchestration de jobs seront eux-mêmes pilotés par l'intelligence artificielle : allocation dynamique des ressources en fonction de la charge prédite, priorisation intelligente des documents urgents (une souscription en cours vs un archivage différé), routage optimal vers le canal le moins chargé. Ragindeed explore déjà cette direction avec ses agents orchestrateurs capables d'adapter le flux de traitement en fonction du contexte.
L'ASPIM (Association française des sociétés de placement immobilier, « Rapport annuel sur la transformation numérique des SGP, 2025 ») constate que 78 % des sociétés de gestion immobilière françaises considèrent l'automatisation du traitement documentaire comme une priorité stratégique pour 2025-2027. La file de jobs, invisible pour l'utilisateur final, est le moteur silencieux qui rend cette automatisation possible à grande échelle.
Le traitement en arrière-plan de Ragindeed absorbe vos pics de volume documentaire sans jamais ralentir vos équipes. Demandez une démonstration avec un import réel depuis votre SharePoint ou OneDrive.
Références :
- AIIM, « State of the Intelligent Information Management Industry, 2025 »
- IDC, « Worldwide Intelligent Document Processing Forecast, 2025-2029 », février 2025
- Gartner, « Market Guide for Intelligent Document Processing Solutions, 2025 »
- Gartner, « Predicts 2026: AI Engineering », décembre 2025
- Forrester, « The Future of Document Processing Infrastructure, 2025 »
- McKinsey, « Operations of the future: How digital and AI are transforming asset management », 2025
- AMF, « Instruction AMF 2012-01 relative à l'organisation de la gestion des risques »
- ACPR, « Recommandations sur la transformation numérique des acteurs financiers », 2024
Le traitement en arrière-plan gère vos volumes sans ralentir votre interface. Tester avec vos propres documents →