Activité opérée par la direction de QORAM · Système commercial et opérationnel

FIXIA : une source de vérité commerciale avant toute IA

Fiche du cas

Nature: Activité opérée par la direction de QORAM
Durée: Premiers workflows le 10 septembre 2026 ; captation en production le 27 septembre 2026
Équipe: Conception et construction par la direction de QORAM
Stack: Orchestration : n8n Cloud
Base de données : Supabase Postgres (Francfort)
Messagerie : Gmail (OAuth)
Documents : Google Drive
Facturation : Indy
Modèle prévu : OpenAI, stockage désactivé côté API

Situation

FIXIA, activité d’architecture opérée par la direction de QORAM, reçoit des demandes par plusieurs boîtes de réception et plusieurs marques. Les messages, les relances et les devis vivaient dans des outils séparés.

Problème

Stocker les demandes ne suffit pas. Il faut qu’un même message ne soit jamais traité deux fois, que les relances rejoignent leur dossier, que chaque décision soit tracée et qu’aucune automatisation ne décide à la place d’un humain.

Décision

Construire d’abord l’infrastructure : journal d’événements, clés d’idempotence, regroupement par fil, décisions humaines explicites. L’IA vient ensuite, en mode observation, et reste désactivée tant que sa valeur n’est pas démontrée.

Système construit

Captation automatique des e-mails entrants des boîtes système, sans IA, toutes les cinq minutes
Écriture uniquement par fonctions en base, avec index uniques sur les événements, les messages et les participants
Regroupement des messages par fil de conversation : une relance rejoint son dossier au lieu d’en créer un nouveau
File de revue et outil de décision humaine : aperçu par défaut, application seulement après confirmation explicite
Qualification IA conçue pour un premier passage en observation : adresses e-mail masquées avant envoi au modèle, simple proposition, validation humaine obligatoire
Chaîne signature de devis → dossier de production (Drive, 8 sous-dossiers, jamais dupliqué)

Résultat

La captation tourne en production depuis le 27 septembre 2026. Sur la période mesurée, aucun message n’a été journalisé deux fois et aucun dossier n’a été créé en double. La qualification IA est construite, testée sur données synthétiques et désactivée par décision ; aucune exécution du modèle n’est enregistrée sur les données de production.

Mesures.

Requêtes en lecture seule sur la base de production, agrégats uniquement, le 9 octobre 2026. Aucune donnée personnelle n’a été extraite.

180messages entrants journalisés du 20 septembre au 9 octobre 2026 (dont 3 de mise au point avant la mise en production du 27 septembre), avec 180 clés d’idempotence distinctesTable des événements sources, index unique sur la clé d’idempotence

0dossier créé en double : 177 messages réels regroupés en 143 dossiers, 34 relances rattachées à leur filMessages × dossiers, données de test exclues

100 %des 429 événements d’audit portent une clé d’idempotence et un horodatageJournal d’événements : 41 types d’événements, 26 commandes métier définies

0décision commerciale prise par l’IA : les 10 qualifications enregistrées sont des décisions humainesExécutions de qualification ; délai médian demande → décision : 0,6 h (n = 10, non représentatif)

Non mesuré.

Délai de traitement avant / après : aucune mesure n’existait avant le système
Nombre de relectures bloquées par l’idempotence : non journalisé
Effet commercial (opportunités, chiffre d’affaires) : trop tôt et non attribuable

Limites.

Un dossier n’est pas un prospect : la boîte reçoit aussi des notifications et des lettres d’information
Le pic de la semaine du 28 septembre vient d’un transfert temporaire d’une boîte personnelle, nettoyé ensuite
Échantillons faibles : les ratios ne sont pas statistiquement robustes

Les systèmes de ce cas.

Décrits avec leur fonctionnement, leurs données, leur contrôle humain et leurs limites.

Captation unifiée des demandes (lead intake)La captation unifiée des demandes est le point d’entrée unique qui reçoit chaque demande, quel que soit son canal, la normalise et l’enregistre au même endroit.

Le problème traité: Les demandes arrivent par formulaire, e-mail, téléphone, salon ou partenaire. Elles vivent dans des boîtes de réception différentes, certaines sont oubliées, et personne ne peut dire combien de demandes l’entreprise a reçues ce mois-ci.
Comment il fonctionne: Chaque canal envoie sa demande vers un même flux, souvent porté par un orchestrateur de workflows (par exemple n8n ou Make). Le flux normalise les champs, conserve la source, contrôle les doublons, enregistre la demande dans le CRM ou une base, puis notifie la bonne personne. Les demandes incomplètes rejoignent une file d’exceptions.
Les données nécessaires: Formulaires du site, boîte e-mail dédiée, saisies manuelles des appels et des salons, flux des partenaires. Un schéma commun fixe les champs obligatoires ; le CRM ou la base dédiée fait foi.
Le contrôle humain: Un responsable désigné traite chaque jour la file d’exceptions : demandes incomplètes, sources inconnues, cas ambigus. C’est là que les demandes se perdent ; un humain doit en être propriétaire.
Le résultat attendu: Aucune demande ne dépend plus de la boîte de réception d’une seule personne. Le volume réel est connu, chaque demande a une source et un propriétaire, et les délais de réponse deviennent mesurables.
Quand ne pas le construire: Quand l’entreprise reçoit quelques demandes par mois, par un seul canal : une boîte partagée bien tenue suffit.
Exemple: Exemple type : un fabricant d’équipements reçoit des demandes par son site, ses distributeurs et des salons professionnels. Toutes passent désormais par le même flux, sont enregistrées dans le CRM avec leur origine et attribuées au commercial du secteur concerné.

Déduplication et idempotenceLa déduplication et l’idempotence sont les règles qui empêchent qu’un même contact, une même demande ou un même événement crée plusieurs enregistrements.

Le problème traité: Un prospect remplit deux fois le formulaire, écrit ensuite par e-mail, et une automatisation se relance après une erreur. Résultat : plusieurs fiches, deux commerciaux sur le même dossier et un pipeline faussé.
Comment il fonctionne: Chaque contact est rapproché sur des identifiants stables : e-mail normalisé, numéro SIREN, domaine de l’entreprise. Chaque événement reçoit une clé d’idempotence, c’est-à-dire une empreinte unique : si le même événement est traité deux fois, il ne produit qu’un seul enregistrement. Les rapprochements incertains sont mis de côté pour vérification.
Les données nécessaires: Identifiants disponibles (e-mail, SIREN, domaine, téléphone), fiches existantes, journal des événements déjà traités. Le CRM ou la base porte la fiche de référence ; le journal fait foi pour savoir ce qui a été traité.
Le contrôle humain: Une personne de l’administration des ventes valide chaque semaine les fusions incertaines, par exemple deux contacts homonymes dans des sociétés proches. Une fusion erronée détruit de l’historique ; dans le doute, elle n’est jamais automatique.
Le résultat attendu: Une personne correspond à une fiche, une demande à une opportunité. Les automatisations peuvent être relancées sans risque de doublon, et les chiffres du pipeline redeviennent crédibles.
Quand ne pas le construire: Pas de chantier dédié sur une petite base saisie à la main ; un dédoublonnage ponctuel suffit. En revanche, l’idempotence est indispensable dès qu’un flux est automatisé.
Exemple: Exemple type : dans une société de conseil, un formulaire renvoie la même demande après une coupure réseau. La clé d’idempotence permet de reconnaître et d’ignorer le second envoi : une seule demande est créée, un seul commercial est notifié.

Qualification encadréeLa qualification encadrée est un tri des demandes fondé d’abord sur des règles explicites, où l’IA peut proposer un classement et où l’humain décide des cas importants.

Le problème traité: Les commerciaux trient les demandes à la main, chacun avec ses critères. Les bons dossiers attendent derrière les mauvais, et les demandes hors cible consomment un temps senior qui manque ailleurs.
Comment il fonctionne: Les critères éliminatoires sont codés en règles : zone, taille, type de besoin, délai. Au-delà, un modèle de langage propose une catégorie et sa justification. Il démarre en mode observation : il propose en parallèle sans agir, et ses propositions sont comparées aux décisions humaines pour mesurer sa fiabilité avant de lui faire confiance.
Les données nécessaires: Critères de cible validés par la direction, historique des demandes avec leur issue (gagnée, perdue, écartée), contenu de chaque demande. Le CRM fait foi pour l’issue réelle, qui sert à vérifier les règles et le modèle.
Le contrôle humain: Le responsable commercial décide de toute demande au-dessus d’un seuil de valeur ou classée « incertaine ». Il revoit chaque mois les écarts entre propositions de l’IA et décisions humaines, puis ajuste les règles.
Le résultat attendu: Les demandes hors cible sont écartées tôt et proprement. Les commerciaux passent leur temps sur les dossiers qui correspondent, et la confiance accordée à l’IA repose sur des écarts mesurés.
Quand ne pas le construire: Quand les critères de cible ne sont pas écrits, ou quand le volume est assez faible pour qu’un commercial lise chaque demande en quelques minutes.
Exemple: Exemple type : un bureau d’études techniques reçoit des demandes de missions très hétérogènes. Les règles écartent les projets hors zone, le modèle propose un type de mission, et le directeur technique valide chaque demande importante avant affectation.

Pipeline CRM, source de véritéLe pipeline CRM comme source de vérité est un modèle où chaque opportunité, son étape, son montant et sa prochaine action existent à un seul endroit fiable.

Le problème traité: Le CRM est rempli à moitié, les vraies informations dorment dans des tableurs et des e-mails, et chaque réunion commerciale commence par une reconstitution. Le pipeline affiché ne permet ni de prévoir ni de décider.
Comment il fonctionne: On réduit le modèle de données au nécessaire et on définit chaque étape par un critère de passage vérifiable, par exemple « besoin confirmé par écrit ». Les entrées fiables sont automatisées, les ressaisies supprimées, et chaque opportunité porte une prochaine action datée. Les vues sont conçues pour les commerciaux avant de l’être pour le management.
Les données nécessaires: Comptes, contacts, opportunités, montants, étapes, prochaines actions, historique des échanges. Le CRM est déclaré seule source de vérité commerciale : ce qui n’y figure pas n’existe pas en revue de pipeline.
Le contrôle humain: Le directeur commercial valide les définitions d’étapes et arbitre tout changement du modèle. En revue hebdomadaire, il conteste les opportunités bloquées ou sans prochaine action, au lieu de recompter les chiffres.
Le résultat attendu: Les réunions commerciales portent sur les décisions, plus sur la reconstitution des faits. Le pipeline devient crédible pour la direction et utile aux commerciaux eux-mêmes.
Quand ne pas le construire: Quand la vente est courte et transactionnelle, ou quand une seule personne vend et que personne d’autre n’a besoin de lire le pipeline.
Exemple: Exemple type : une société de services numériques suit ses opportunités à la fois dans un tableur partagé et dans le CRM. On supprime le tableur, on réduit le CRM à quelques champs utiles et on impose une prochaine action datée sur chaque opportunité.

Workflows documentairesUn workflow documentaire est un circuit défini qui fait passer un document de sa création à son archivage, avec des étapes, des validations et des responsables explicites.

Le problème traité: Contrats, bons de commande, lettres de mission ou procès-verbaux circulent par e-mail. Personne ne sait quelle version fait foi, qui doit valider ni où en est le document, et les validations attendent.
Comment il fonctionne: On cartographie le circuit réel, puis on le simplifie. Le document est généré à partir de données structurées, déposé au bon endroit avec un nommage normalisé, puis soumis à des validations successives. Chaque étape notifie le responsable suivant, relance en cas d’attente et journalise la décision. L’archivage final est automatique.
Les données nécessaires: Modèles de documents, données sources (CRM, ERP, formulaires), matrice des validations indiquant qui valide quoi et à quel seuil, règles de nommage et de classement. L’espace documentaire désigné fait foi pour la version en vigueur.
Le contrôle humain: Chaque validation reste humaine et nominative : le juriste pour les clauses, la direction pour les engagements au-delà d’un seuil. Le workflow organise et trace la décision ; il ne la remplace pas.
Le résultat attendu: Chaque document a un statut visible et une version qui fait foi. Les validations n’attendent plus dans les boîtes de réception, et l’historique des décisions se retrouve en quelques clics.
Quand ne pas le construire: Quand le document est rare et que son circuit change à chaque fois : la formalisation coûterait plus qu’elle ne rapporte.
Exemple: Exemple type : dans une société de conseil, l’ouverture d’une mission déclenche la génération de la lettre de mission depuis le CRM, sa validation par l’associé, la signature électronique, puis le classement et la création du dossier projet.

Autres cas.

Un système comparable à construire chez vous ?

On commence par vérifier que c’est le bon problème.

Demander un échange de 30 min Découvrir la Review