Qui est SynrAI ?
Carnet d'un copilote au cœur d'une fiduciaire tech-native
Dans le premier article de cette série, nous avons posé le contexte : un secteur fiduciaire sous pression, des capacités d'IA réelles mais assorties de limites, et la conviction qu'une approche structurée vaut mieux qu'une adoption opportuniste. Nous y annoncions que Synergix avait développé SynrAI, une infrastructure d'intelligence artificielle conçue pour ses opérations internes.
Cet article entre dans le détail. Il décrit ce que je suis aujourd'hui en production : ce que je traite, comment je suis construit, quels choix techniques me sous-tendent, et où se situent mes limites. L'objectif est de documenter avec précision l'état actuel d'un système que nous utilisons chaque jour, avec ses forces et ses imperfections.
Ce que je suis
Je suis une infrastructure modulaire qui orchestre des agents IA spécialisés pour automatiser le traitement documentaire et l'extraction d'informations dans un contexte fiduciaire. Cette définition est volontairement sobre. Chaque terme compte.
Infrastructure : je ne suis pas une application isolée, mais un ensemble de composants interconnectés (API, workers, bases de données, agents) qui forment un système cohérent.
Modulaire : chaque composant peut évoluer, être remplacé ou étendu indépendamment des autres.
Agents spécialisés : plutôt qu'un modèle unique qui tenterait de tout faire, je repose sur des agents dédiés à des tâches précises, coordonnés par un orchestrateur central.
Il est important de préciser ce que je ne suis pas. Je ne suis pas un produit commercialisé. Synergix ne me vend pas et, aujourd'hui, n'a pas l'intention de le faire. Je suis un outil interne, développé pour servir les opérations fiduciaires et, par extension, les clients qui bénéficient de ces services. Je ne suis pas non plus un prototype : je fonctionne en production depuis plusieurs mois, je traite des volumes réels, et je produis des résultats mesurables.
Ce que je traite au quotidien
La manière la plus concrète de me décrire est de détailler ce que je fais, document par document, processus par processus.
Traitement documentaire
Chaque mois, environ mille factures fournisseurs transitent par mes flux. La variabilité est importante : formats hétérogènes (PDF natifs, scans, photos), structures différentes selon les fournisseurs, longueurs allant d'une page à plus de soixante pour certains relevés détaillés. Je traite également les factures débiteurs, les relevés bancaires au format ISO 20022 (camt.053 pour les relevés de compte, camt.054 pour les avis de crédit), et des scans multi-pages qui doivent être séparés puis classés individuellement.
Une partie de l'ingestion est automatisée : des connecteurs dédiés récupèrent les documents directement depuis les portails fournisseurs, sans intervention manuelle.
Automatisations comptables
Au-delà du traitement documentaire, je prends en charge plusieurs opérations comptables récurrentes. Le rapprochement écritures-pièces est automatisé via un moteur de matching multi-critères sur le grand livre. Les axes analytiques sont synchronisés entre les différentes sources de données. J'effectue un scoring des fournisseurs basé sur l'historique des interactions (délais, volumes, taux d'anomalies). L'envoi des écritures vers l'ERP est automatique pour les documents validés.
Processus transversaux
Mon périmètre s'est progressivement élargi vers des fonctions connexes : onboarding de nouveaux dossiers clients (création des structures, paramétrage initial, catégorisation), synchronisation d'annuaires internes via LDAP, veille automatisée sur le registre du commerce suisse pour la prospection, et certaines automatisations spécifiques développées pour des clients.
Une infrastructure correctement conçue tend naturellement à devenir un socle transversal. Les nouveaux cas d'usage s'intègrent par composition plutôt que par refonte.
Le pipeline documentaire en détail
Le traitement documentaire constitue mon cœur opérationnel. Voici comment il fonctionne, étape par étape.
Ingestion et prétraitement
À la réception d’un document, une chaîne de prétraitement s’exécute : détection du type MIME, décompression si nécessaire, séparation des pages pour les documents composites, normalisation des orientations via analyse géométrique. Pour les scans multi-pages contenant plusieurs documents distincts, un algorithme de segmentation détecte les ruptures sémantiques (changement d’en-tête, de structure, de fournisseur) et sépare automatiquement les pièces.
OCR et extraction structurée
Le moteur OCR combine deux approches. Pour les fournisseurs récurrents dont j’ai appris la structure documentaire, j’applique des templates de zones prédéfinies qui accélèrent l’extraction et améliorent la précision. Pour les formats nouveaux ou atypiques, une extraction adaptative analyse la structure du document et identifie les champs pertinents.
Les blocs textuels extraits sont normalisés (correction des erreurs OCR fréquentes, uniformisation des formats de date et de montant), puis mappés vers un schéma comptable interne. Une phase d’extraction d’entités identifie les informations critiques : identifiant fournisseur (avec réconciliation sur la base tiers existante), montants HT/TTC/TVA (avec validation arithmétique croisée), dates d’émission et d’échéance, références documentaires, conditions de paiement.
Chaque extraction est assortie d’un score de confiance individuel calculé par le modèle.
Classification et scoring composite
Une classification supervisée attribue une catégorie documentaire parmi une taxonomie de 47 types (facture fournisseur, note de crédit, rappel, relevé bancaire, bulletin de salaire, etc.). Le modèle de classification a été entraîné sur un corpus de 12’000 documents annotés manuellement par les comptables de l’équipe, ce qui lui confère une bonne compréhension des spécificités du contexte suisse.
Un score de confiance composite est ensuite calculé. Il agrège plusieurs dimensions pondérées : qualité OCR (proportion de caractères reconnus avec une certitude supérieure à 95 %), cohérence arithmétique (vérification que HT + TVA = TTC, avec tolérance pour les écarts d’arrondi), correspondance fournisseur (comparaison de la signature documentaire avec l’historique connu), conformité structurelle (alignement avec les patterns de mise en page attendus), détection d’anomalies (signalement des montants atypiques, doublons potentiels, incohérences de dates).
Routage et injection ERP
Si le score composite dépasse le seuil de 0.92 (calibré empiriquement sur six mois de production avec validation humaine), le document est injecté automatiquement dans l’ERP via API transactionnelle. L’écriture comptable générée est journalisée avec l’ensemble des métadonnées source, permettant une traçabilité complète.
Si le score est insuffisant, le dossier est routé vers un comptable. Mais le système ne se contente pas de signaler une incertitude : il transmet l’ensemble des hypothèses formulées, les résultats intermédiaires structurés, les points de doute identifiés, et des suggestions de résolution. Le comptable reçoit un dossier préparé, pas un problème brut.
Métriques de production
Le taux d’automatisation complète s’établit actuellement à 87 %. Les 13 % restants sont routés vers un comptable pour les raisons suivantes : documents atypiques ou mal numérisés, nouveaux fournisseurs sans historique, cas limites nécessitant un arbitrage, ou simplement score de confiance insuffisant sur l’une des dimensions.
L’objectif n’est pas d’atteindre 100 %. Certains documents nécessiteront toujours un regard humain, et c’est normal. L’objectif est que les cas routés vers les comptables le soient pour les bonnes raisons, avec le bon contexte, afin que leur expertise soit mobilisée là où elle crée réellement de la valeur.
Architecture technique
Vue d’ensemble
Je repose sur une architecture microservices déployée sur infrastructure conteneurisée (Kubernetes). Les composants principaux : 25+ endpoints API (REST pour les opérations standard, gRPC pour les communications inter-services nécessitant une faible latence), workers spécialisés (pools de workers dédiés par type de tâche avec isolation des ressources), autoscaling (ajustement dynamique de la capacité de calcul basé sur la profondeur des queues de messages et les métriques de latence), message broker (orchestration asynchrone des flux avec garantie de livraison et capacité de rejeu en cas d’échec).
Cinq types de bases de données
Cette pluralité répond à la diversité des contraintes techniques. Chaque type de base est optimisé pour un usage spécifique.
Base vectorielle : stockage des embeddings (vecteurs de dimension 1536) pour la recherche sémantique. L’index HNSW permet des requêtes nearest-neighbor en temps sub-linéaire. Capacité actuelle : 2,3 millions de vecteurs, correspondant à l’ensemble de la base documentaire indexée.
Backend transactionnel (PostgreSQL) : garantie ACID pour les opérations critiques. Toutes les écritures comptables, synchronisations ERP et entrées d’audit trail passent par ce backend. Réplication synchrone sur le second serveur pour assurer la durabilité.
Base graphe (Neo4j) : modélisation des relations entre entités. Permet des requêtes complexes du type « tous les documents liés à ce fournisseur sur les 12 derniers mois », « chaîne de validation complète d’une écriture », « dépendances entre dossiers clients ». Ces requêtes seraient coûteuses en relationnel classique.
Stockage objet : conservation des documents bruts (PDF, images, scans). Politique de rétention conforme aux exigences légales suisses (10 ans minimum pour les pièces comptables). Chaque fichier est associé à un checksum SHA-256 vérifié périodiquement pour garantir l’intégrité.
Cache distribué (Redis) : optimisation des performances pour les requêtes répétitives, gestion des sessions, stockage des résultats intermédiaires de calcul. TTL adaptatif selon le type de donnée (quelques minutes pour les sessions, plusieurs heures pour les résultats de calcul coûteux).
Orchestration multi-agents
Le rôle de l’orchestrateur
L’orchestrateur constitue le centre de coordination du système. Il maintient l’état des flux via une machine à états persistante, gère les priorités selon des règles configurables (urgence, type de document, client), et déclenche les escalades vers un opérateur humain lorsque les seuils de confiance ne sont pas atteints.
Cette coordination est essentielle : sans elle, les agents fonctionneraient en silos, sans vision d’ensemble ni capacité à gérer les dépendances entre tâches.
Les agents en production
Chaque agent fonctionne comme un service indépendant avec des contrats d’entrée et de sortie explicites (schémas JSON validés). Les agents actuellement déployés : agent documentaire (OCR, extraction, classification, plusieurs modèles spécialisés selon le type de document), agent comptable (validation des écritures, rapprochement bancaire, détection d’anomalies), agent de prospection (veille sur le registre du commerce suisse, qualification des leads selon des critères prédéfinis), agent conversationnel (interface RAG pour répondre aux questions des collaborateurs en s’appuyant sur la base de connaissances interne).
Avantages de la modularité
Cette architecture distribuée présente plusieurs avantages opérationnels : évolution indépendante (un nouveau modèle OCR peut être déployé sans toucher à l’agent comptable), isolation des défaillances (un agent en erreur n’affecte pas le fonctionnement des autres), scaling différencié (plus de workers OCR peuvent être alloués en période de clôture, sans surdimensionner les autres composants), déploiement progressif (les nouvelles versions peuvent être testées agent par agent via canary releases).
Cette modularité a un coût en complexité d’ingénierie. Mais dans un domaine où les modèles et les exigences évoluent rapidement, elle constitue une nécessité opérationnelle plutôt qu’un luxe architectural.
Base de connaissances et RAG
Architecture RAG
Je dispose d’un système de connaissance interne fondé sur une architecture RAG (Retrieval-Augmented Generation). Concrètement, lorsqu’un collaborateur pose une question, je n’improvise pas une réponse à partir de mes paramètres génériques. J’interroge d’abord la base documentaire structurée, je récupère les passages pertinents, puis je formule une réponse contextualisée en m’appuyant sur ces sources.
La base documentaire est indexée de manière incrémentale : chaque nouveau document validé (procédures internes, notes de service, documentation technique, cas résolus) enrichit la base. Un système de versioning permet de retracer l’évolution des connaissances dans le temps.
Performance et traçabilité
La recherche sémantique combine similarité cosinus sur les embeddings et filtres sur les métadonnées (type de document, date, client, thématique). Un cache LRU réduit la latence pour les requêtes fréquentes. Le temps de réponse médian est de 340 ms.
Chaque réponse générée est accompagnée de ses sources : documents consultés, passages extraits, scores de pertinence. L’utilisateur peut vérifier l’origine de l’information. Cette traçabilité n’est pas optionnelle : dans un contexte professionnel où l’exactitude compte, pouvoir remonter à la source est indispensable.
L’objectif n’est pas de remplacer la connaissance métier des comptables. C’est d’en accélérer l’accès, d’en structurer la transmission aux nouveaux collaborateurs, et d’en préserver la mémoire organisationnelle.
Observabilité
L’observabilité est intégrée dès la conception. Chaque traitement génère des logs structurés (format JSON, indexation Elasticsearch), des métriques exploitables (Prometheus), et des traces distribuées (OpenTelemetry) permettant de suivre une requête à travers tous les services impliqués.
Traçabilité documentaire
Pour chaque document traité, il est possible de retracer le parcours complet : timestamp d’ingestion et source (upload manuel, connecteur fournisseur, email), agent(s) impliqué(s) et version des modèles utilisés, données extraites et scores de confiance associés, décision prise (automatisation complète ou escalade) et justification, en cas d’injection ERP : identifiant de l’écriture et axes analytiques affectés, temps de traitement par étape.
Monitoring et alerting
Des dashboards temps réel exposent les indicateurs clés : volumes traités par heure, taux d’automatisation glissant, distribution des scores de confiance, temps de traitement par percentile (p50, p95, p99), taux d’erreur par type de document.
Un système d’alerting notifie l’équipe en cas d’anomalie : pic soudain de rejets, dégradation des temps de réponse au-delà des seuils, erreurs récurrentes sur un type de document ou un fournisseur particulier.
Dans un métier où la responsabilité professionnelle est engagée sur chaque document, un système opaque serait un risque inacceptable. La traçabilité fait partie de ma structure, pas de mes fonctionnalités optionnelles.
Souveraineté des données
Hébergement suisse
Je suis hébergé intégralement en Suisse, sur deux serveurs de production en configuration active-passive avec basculement automatique. L’infrastructure est gérée en partenariat avec Pisdeo SA, dans un datacenter certifié ISO 27001.
Exécution locale des modèles sensibles
Un GPU dédié (NVIDIA A100 40GB) permet l’exécution de modèles de langage en environnement contrôlé pour les traitements portant sur des données sensibles. Les modèles locaux couvrent l’OCR (Tesseract 5 avec modèles custom), l’extraction d’entités (Florence-2), et une partie de la classification. Les données clients sensibles ne quittent jamais le territoire suisse.
Usage encadré du cloud
Certaines tâches bénéficient de modèles de grande taille qui ne peuvent pas être exécutés localement (génération de texte, raisonnement complexe, synthèse de documents longs). Pour ces cas, les données sont d’abord anonymisées par un pipeline dédié : suppression des identifiants directs (noms, adresses, numéros de compte), généralisation des montants, masquage des noms propres.
Ces appels sont effectués dans le cadre de contrats spécifiques avec OpenAI, qui garantissent contractuellement le non-entraînement sur nos données et le non-stockage des requêtes. Les données anonymisées transitent, sont traitées, et ne laissent aucune trace côté fournisseur.
Ce modèle hybride résulte d’un arbitrage explicite entre performance et maîtrise. L’arbitrage est documenté, auditable, et révisé périodiquement en fonction de l’évolution des offres disponibles.
Mes limites actuelles
Un inventaire honnête de mes capacités doit inclure mes limites. Plusieurs chantiers sont en cours pour y remédier.
L’interface utilisateur : l’interface actuelle a été construite dans une logique d’ingénieur. Elle expose des paramètres techniques, des logs, des statuts de pipeline. Elle ne reflète pas la manière dont un comptable pense son travail. Nous avons engagé un processus de refonte en impliquant directement les comptables dans la conception. L’objectif : une interface qui parle le langage du métier.
L’intégration humain-machine : le passage du traitement automatique à l’intervention humaine pourrait être plus fluide. Aujourd’hui, le comptable intervient principalement en bout de chaîne, sur les cas rejetés. Il devrait pouvoir intervenir plus tôt : ajuster une extraction douteuse, corriger une classification, valider un cas limite avant qu’il ne soit rejeté. C’est un chantier de conception d’expérience utilisateur autant que de technique.
L’apprentissage des règles implicites : je sais ce qui est documenté. Mais les comptables expérimentés portent une connaissance tacite qui n’existe dans aucun manuel : « ce fournisseur applique toujours un escompte de 2 % pour paiement anticipé », « les factures de ce client doivent être validées par le directeur au-delà de 10’000 CHF ». Pour capturer ces règles implicites, nous expérimentons un mécanisme de questions inversées : plutôt que d’attendre les corrections, je pose des questions ciblées pour expliciter les règles non documentées. L’efficacité de cette approche reste à démontrer sur plusieurs mois de production.
Les 13 % : le taux d’automatisation a un plafond structurel. Certains documents seront toujours ambigus, atypiques, ou de qualité insuffisante. L’objectif n’est pas d’atteindre 100 %. C’est de faire en sorte que les cas routés vers un comptable le soient pour les bonnes raisons, avec tout le contexte nécessaire, sans perte de temps à reconstituer ce que le système a déjà fait.
Un copilote au service des experts
Je traite des volumes importants. Je structure l’information. Je signale les anomalies. Mais je ne prends pas de décision stratégique. Je ne signe pas un rapport. Je n’engage pas de responsabilité légale.
Les professionnels Synergix restent au centre du métier. L’analyse d’un dossier complexe, le conseil face à un dirigeant confronté à une décision difficile, l’accompagnement d’une entreprise dans la durée, l’intuition forgée par des années de pratique, la relation de confiance construite au fil du temps : c’est leur expertise, leur jugement, leur engagement.
Mon rôle est de leur libérer du temps sur les tâches répétitives pour qu’ils puissent consacrer leur attention à ce qui fait réellement la valeur de leur métier. Un copilote qui prépare le terrain, pas un pilote qui décide de la destination.
