Pain in front. AI behind.

Des systèmes qui tiennent en production, avec l’IA là où elle se mesure.

Six conditions avant tout projet d’IA.

Si l’une manque, on la construit d’abord, ou on ne fait pas le projet.

Un cas d’usage à impact

Un processus fréquent, coûteux ou risqué. Pas une démonstration.

Des données disponibles

Les sources existent, sont accessibles et font foi.

Un niveau de risque connu

Ce qui se passe si le modèle se trompe, et qui le voit.

Une supervision définie

Qui valide, à quelle étape, avec quel droit de blocage.

Un coût actuel mesuré

Temps, erreurs, délais : la base de comparaison existe avant le projet.

Un gain mesurable

Le critère de succès est écrit avant la construction.

Quatre niveaux d’autonomie. On monte un niveau à la fois.

Chez FIXIA, la qualification IA est construite et testée sur données synthétiques, puis désactivée par décision avant le niveau observation. Chez L’Architecte ERP, elle est au niveau assisté, avec revue humaine imposée par le code.

Règles, sans IA
Ce qui peut s’écrire en règles s’écrit en règles : plus fiable, moins cher, auditable.
IA en observation
Le modèle propose en parallèle, sans rien déclencher. On compare ses propositions aux décisions humaines.
IA assistée
Le modèle prépare, l’humain valide. Chaque proposition et chaque décision sont journalisées.
Agent encadré
Des actions bornées, des permissions explicites, une validation avant tout acte irréversible. Rarement nécessaire.

6 systèmes

Croissance et distribution

Faire trouver l’entreprise et transformer l’intention en demande.

Architecture d’acquisitionL’architecture d’acquisition est le plan qui relie chaque canal de demande à une offre, une page, une étape de qualification et une mesure dans le pipeline.

Le problème traité: Les canaux s’ajoutent un par un : référencement, salons, publicité, réseau. Chacun produit son propre indicateur, aucun ne dit ce qu’il apporte au pipeline, et le budget suit l’habitude plutôt que la preuve.
Comment il fonctionne: On part des segments et des intentions d’achat, puis on attribue à chaque canal un rôle précis : créer la demande, la capter ou la convertir. Chaque canal pointe vers une page dédiée, un formulaire qualifiant et une étape CRM. Les canaux sans rôle clair sont arrêtés ou mis en test.
Les données nécessaires: Sources actuelles des demandes, coûts par canal, historique des opportunités et des signatures. Le CRM fait foi pour le résultat commercial ; les outils publicitaires ne servent qu’à mesurer l’amont.
Le contrôle humain: La direction commerciale arbitre le rôle et le budget de chaque canal chaque trimestre, sur la base du pipeline réel. Aucun canal n’est ajouté sans hypothèse écrite ni critère d’arrêt.
Le résultat attendu: Chaque euro d’acquisition a une fonction lisible. Les canaux qui ne nourrissent pas le pipeline sont identifiés et coupés, et la discussion budgétaire repose sur des opportunités, non plus sur du trafic.
Quand ne pas le construire: Quand l’offre n’est pas encore claire ou que l’équipe commerciale ne peut pas traiter plus de demandes : il faut d’abord régler l’offre ou la capacité.
Exemple: Exemple type : un sous-traitant industriel finance des salons, un site et de la publicité en ligne sans savoir d’où viennent ses consultations. L’architecture rattache chaque source à une page et à une étape CRM, puis la direction réalloue l’effort au trimestre suivant.

Pages d’intentionUne page d’intention est une page conçue pour répondre à une recherche précise d’un acheteur, avec la réponse, la preuve et la prochaine étape adaptées.

Le problème traité: Le site parle de l’entreprise, pas des situations de ses clients. Un acheteur qui cherche une réponse à un problème précis tombe sur une page générique, ne se reconnaît pas et repart sans rien demander.
Comment il fonctionne: On recense les intentions réelles : questions posées aux commerciaux, recherches observées, motifs de demande. Chaque intention distincte reçoit une page : réponse directe en tête, conditions d’application, preuves, limites, puis une prise de contact qualifiante. Les intentions trop proches sont regroupées pour éviter les pages quasi identiques.
Les données nécessaires: Questions entendues par les commerciaux, requêtes remontées par la Search Console, motifs de contact enregistrés dans le CRM. La source de vérité reste ce que les clients demandent réellement, pas une liste de mots-clés.
Le contrôle humain: Un expert métier valide le fond de chaque page avant publication : exactitude technique, conditions, limites. Le dirigeant tranche la liste des intentions à couvrir, car chaque page engage la promesse de l’entreprise.
Le résultat attendu: Les visiteurs arrivent sur une réponse à leur question, pas sur une plaquette. Les demandes entrantes sont plus précises et le commercial sait d’emblée quel problème il doit traiter.
Quand ne pas le construire: Quand l’entreprise vend une seule offre à un seul type d’acheteur, ou quand personne en interne ne peut valider le contenu technique des pages.
Exemple: Exemple type : un bureau d’études fluides reçoit surtout des demandes vagues. Il crée des pages distinctes pour la mise en conformité d’un établissement recevant du public, la rénovation énergétique d’un plateau tertiaire et l’audit technique avant acquisition, chacune avec sa réponse, ses limites et un formulaire adapté.

Architecture SEO / GEOL’architecture SEO / GEO est l’organisation du site, des contenus et des signaux d’entité qui rend l’entreprise trouvable dans Google et citable par les moteurs génératifs.

Le problème traité: Le site accumule des pages sans hiérarchie, des messages contradictoires et peu de preuves vérifiables. Les moteurs de recherche le comprennent mal, et les moteurs génératifs citent d’autres sources quand on les interroge sur le métier.
Comment il fonctionne: Le SEO structure l’arborescence, le maillage et les données structurées. Le GEO vise la visibilité dans les réponses des moteurs génératifs. La GEA (Generative Engine Authority, discipline interne à QORAM, pas un standard officiel) construit les preuves, la cohérence de l’entité et les sources citables qui conduisent un moteur génératif à retenir l’entreprise comme source.
Les données nécessaires: Pages existantes, Search Console, requêtes réelles, profils externes de l’entreprise (annuaires, réseaux, fiches), références publiables. La source de vérité de l’entité est une fiche interne unique : nom, activités, zones, dirigeants, preuves.
Le contrôle humain: Le dirigeant valide la fiche d’entité et chaque affirmation publiée. Un expert relit les contenus de réponse avant mise en ligne : une erreur reprise par un moteur génératif est difficile à corriger ensuite.
Le résultat attendu: L’entreprise est décrite de la même façon partout. Les pages répondent clairement aux questions du métier, ce qui rend l’entreprise plus facile à indexer, à comprendre et à citer. Aucune citation n’est garantie.
Quand ne pas le construire: Quand le site souffre de problèmes techniques de base non résolus, ou quand l’entreprise n’a aucune preuve publiable : il faut d’abord produire la matière.
Exemple: Exemple type : une PME de services informatiques est décrite différemment sur son site, ses annuaires et ses profils. On unifie la fiche d’entité, on restructure les pages par question client et on publie des références vérifiables. Les moteurs disposent enfin d’une version cohérente à reprendre.

Site comme actif de distributionLe site comme actif de distribution est un site conçu pour produire des demandes qualifiées et les transmettre au système commercial, et non pour présenter l’entreprise.

Le problème traité: Le site a été pensé comme une vitrine. Il est refait périodiquement, n’est relié à aucun outil commercial, et personne ne sait quelles pages produisent des demandes ni lesquelles n’en produisent aucune.
Comment il fonctionne: L’ordre est fixe : business, demande, offre, positionnement, architecture, puis site. Chaque page a un rôle (capter, rassurer, convertir), chaque formulaire alimente le CRM avec sa source, et chaque conversion est mesurée. Le site devient un composant du système, maintenu et amélioré page par page.
Les données nécessaires: Offres et segments validés, preuves disponibles, intentions prioritaires, structure du CRM prête à recevoir les demandes. Le CRM fait foi pour la qualité des demandes ; l’outil d’analytics, pour le comportement de navigation.
Le contrôle humain: Le dirigeant valide la promesse et l’arborescence. Le responsable commercial valide les champs de formulaire et les règles de transmission, car ils déterminent la qualité des demandes que son équipe recevra.
Le résultat attendu: Le site est jugé sur les demandes qu’il produit et sur leur qualité, plus sur son apparence. Chaque évolution part d’une page mesurée, pas d’une refonte globale.
Quand ne pas le construire: Quand les ventes passent exclusivement par un réseau fermé de prescripteurs, ou quand l’offre et la cible ne sont pas encore arrêtées.
Exemple: Exemple type : une entreprise de design & build de bureaux dispose d’un site soigné mais muet. On réorganise les pages autour des situations de ses clients (déménagement, regroupement de sites, réaménagement), on relie les formulaires au CRM et on mesure les demandes par page.

Mesure et attributionLa mesure et l’attribution sont le dispositif qui relie chaque demande à sa source, puis la suit jusqu’à l’opportunité, la signature et le chiffre d’affaires.

Le problème traité: Les rapports parlent de visites, de clics et de formulaires. Personne ne sait quel canal produit des clients signés : les budgets se décident à l’intuition, et de bons canaux sont parfois coupés.
Comment il fonctionne: Chaque demande reçoit sa source à l’entrée : paramètres de campagne, page d’origine, déclaration du contact. Cette source est conservée dans le CRM jusqu’à la signature. Un tableau croise sources, opportunités, taux de transformation et délais. Le modèle d’attribution reste simple et documenté, pour être compris par ceux qui décident.
Les données nécessaires: Paramètres de campagne, événements du site, champs source du CRM, montants signés. Le CRM est la source de vérité du résultat ; les plateformes publicitaires ne sont jamais juges de leur propre performance.
Le contrôle humain: Le responsable marketing ou commercial vérifie chaque mois les demandes sans source et corrige les règles de collecte. La direction interprète les écarts : un chiffre d’attribution éclaire une décision, il ne la prend pas.
Le résultat attendu: Les décisions de budget reposent sur des clients signés et des délais observés, plus sur des volumes de trafic. Les canaux faibles comme les canaux sous-estimés deviennent visibles.
Quand ne pas le construire: Quand le volume de demandes est trop faible pour conclure, ou quand le CRM n’est pas tenu : la mesure ne vaut que ce que vaut la donnée.
Exemple: Exemple type : un organisme de formation inter-entreprises finance plusieurs canaux sans lien avec ses inscriptions. Chaque demande garde sa source jusqu’à la facture, et la direction compare enfin les canaux sur les contrats signés plutôt que sur les clics.

Architecture d’offreL’architecture d’offre est la structure qui organise ce que l’entreprise vend : offres, niveaux, périmètres, prix et portes d’entrée, lisibles par l’acheteur comme par l’équipe.

Le problème traité: L’offre s’est construite par accumulation de demandes clients. Les commerciaux improvisent les périmètres, les prix varient sans logique, et l’acheteur ne comprend ni ce qu’il achète ni pourquoi choisir cette entreprise.
Comment il fonctionne: On inventorie ce qui est réellement vendu et livré, avec la marge de chaque prestation. On regroupe le tout en un petit nombre d’offres nommées, chacune avec un périmètre, des exclusions, un prix ou une règle de prix, et une porte d’entrée simple. Les offres peu rentables ou mal livrées sont arrêtées.
Les données nécessaires: Historique des ventes et des devis, marges par prestation, temps passés, retours clients, motifs de perte. La comptabilité analytique fait foi pour la marge ; le CRM, pour ce qui se vend réellement.
Le contrôle humain: Le dirigeant décide des offres arrêtées, des prix et des exclusions : ce sont des choix de positionnement. L’équipe commerciale est consultée sur la vendabilité de chaque offre avant sa mise en œuvre.
Le résultat attendu: L’acheteur comprend plus vite ce qu’il achète. Les devis partent d’une base commune, les écarts de prix s’expliquent et la marge devient pilotable offre par offre.
Quand ne pas le construire: Quand l’activité repose sur des projets uniques sans aucune récurrence, ou quand le vrai problème est la capacité de livraison, pas la lisibilité de l’offre.
Exemple: Exemple type : une société de maintenance d’équipements industriels vend des dizaines de variantes de contrats. Elle les regroupe en quelques niveaux de service aux périmètres et exclusions explicites, ce qui simplifie à la fois la vente, le devis et la facturation.

6 systèmes

Système commercial

Ne perdre aucune demande, ne rien traiter deux fois, décider vite.

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é.

Relances et suiviLe système de relances et de suivi est un ensemble de règles qui fait qu’aucun devis ni aucune opportunité ne reste sans prochaine action.

Le problème traité: Les devis partent, puis plus rien. Les relances dépendent de la mémoire de chaque commercial, se font hors CRM ou pas du tout, et des affaires gagnables se perdent par simple silence.
Comment il fonctionne: Chaque étape du pipeline déclenche une séquence définie : délai, canal, contenu type. Le système crée la tâche, prépare un brouillon d’e-mail contextualisé à partir du CRM et alerte le commercial. Les relances sensibles restent rédigées à la main. Toute réponse du client arrête la séquence.
Les données nécessaires: Date d’envoi des devis, étape et montant de l’opportunité, historique des échanges, coordonnées à jour. Le CRM fait foi ; une relance n’est déclenchée que si son contexte y est complet.
Le contrôle humain: Le commercial relit et envoie lui-même toute relance portant sur une opportunité importante ou un client existant. Le responsable commercial valide les séquences types, car le ton d’une relance engage la relation.
Le résultat attendu: Les devis ne restent plus sans suite par oubli. Les commerciaux reprennent la main au bon moment, avec un contexte prêt, et le suivi devient visible dans le pipeline.
Quand ne pas le construire: Quand le volume de devis est faible et que le dirigeant suit chaque affaire personnellement : une simple vue « devis en attente » suffit.
Exemple: Exemple type : un fabricant de pièces techniques envoie ses devis sans suivi structuré. Chaque devis génère désormais une tâche de relance datée et un brouillon d’e-mail. Le commercial ajuste, envoie, et la séquence s’arrête dès que le client répond.

Devis et propositions générésLa génération de devis et de propositions est un système qui assemble un document à partir de données structurées, de règles de prix et de contenus validés.

Le problème traité: Chaque devis repart d’un ancien document copié, modifié et parfois mal corrigé. Les délais s’allongent, des erreurs de prix ou de périmètre passent, et la production dépend de quelques personnes.
Comment il fonctionne: Le commercial renseigne une fiche structurée, pré-remplie depuis le CRM. Les règles calculent le prix et les options ; une bibliothèque fournit les blocs de texte validés ; un modèle de langage peut proposer une introduction contextualisée. Le document est généré, soumis à validation, puis archivé et relié à l’opportunité.
Les données nécessaires: Données client et opportunité issues du CRM, grille tarifaire et règles de remise, bibliothèque de clauses et de descriptifs, modèles de documents. La grille tarifaire validée par la direction fait foi pour les prix.
Le contrôle humain: Le commercial relit chaque document avant envoi. Le directeur commercial ou le dirigeant valide tout prix hors grille, toute remise au-delà du seuil et tout engagement non standard : ce sont des décisions de risque.
Le résultat attendu: Les devis partent plus vite et suivent une structure commune. Les erreurs de copier-coller se raréfient, et le temps senior se concentre sur le prix, le risque et les exceptions.
Quand ne pas le construire: Quand chaque proposition est un document stratégique unique, ou quand les règles de prix n’existent pas encore : il faut d’abord les écrire.
Exemple: Exemple type : une entreprise de maintenance CVC chiffre des contrats multisites. Le chargé d’affaires saisit les équipements et la fréquence d’intervention, les règles calculent le prix, le document est généré avec les clauses standard, et toute remise exceptionnelle remonte au directeur.

6 systèmes

Opérations

Faire circuler l’information sans ressaisie, garder les exceptions visibles.

Go / no-go des appels d’offresLe go / no-go des appels d’offres est une grille de décision explicite qui détermine, avant tout travail de rédaction, si un dossier mérite une réponse.

Le problème traité: L’entreprise répond à presque tout, par peur de manquer une affaire. Les équipes s’épuisent sur des dossiers perdus d’avance, et la décision de ne pas répondre arrive tard, après des jours de travail.
Comment il fonctionne: À réception, une fiche de synthèse est produite : objet, montant estimé, délais, critères de jugement, exigences éliminatoires. Un modèle de langage peut aider à extraire ces éléments du règlement de consultation. La fiche est notée sur des critères pondérés : adéquation, marge, capacité, probabilité de gain, risque. Le score éclaire une décision prise en réunion courte.
Les données nécessaires: Règlement de consultation et pièces du marché, historique des réponses gagnées et perdues, plan de charge, références disponibles. L’historique des résultats fait foi pour calibrer la grille.
Le contrôle humain: Le dirigeant ou le directeur des offres prend la décision go / no-go, à date fixe après réception. La grille éclaire ; elle ne décide jamais seule d’un engagement de l’entreprise.
Le résultat attendu: Les ressources se concentrent sur les dossiers gagnables. Le refus est prononcé tôt et argumenté, et la grille s’affine à mesure que les résultats sont enregistrés.
Quand ne pas le construire: Quand l’entreprise répond à très peu d’appels d’offres par an, tous stratégiques : une discussion de direction suffit, sans grille formalisée.
Exemple: Exemple type : une entreprise générale reçoit chaque semaine des consultations publiques et privées. Chaque dossier fait l’objet d’une fiche synthétique et d’un score ; le directeur décide en réunion hebdomadaire, et les dossiers écartés sont archivés avec leur motif.

Bibliothèque de preuves et référencesLa bibliothèque de preuves est un référentiel structuré des références, attestations, CV, certifications et chiffres vérifiés que l’entreprise réutilise dans ses réponses et ses pages.

Le problème traité: Les références sont dispersées dans d’anciens dossiers, les attestations sont introuvables au moment de les joindre, et les descriptifs de projets sont réécrits à chaque réponse, avec des écarts d’un dossier à l’autre.
Comment il fonctionne: Chaque preuve devient une fiche normalisée : client ou maître d’ouvrage, typologie, montant, période, rôle tenu, pièces justificatives, droit de citation. Les fiches sont classées par métadonnées et retrouvables par recherche. Chacune a un propriétaire et une date de validité ; les preuves périmées sont signalées.
Les données nécessaires: Anciennes réponses, attestations de bonne exécution, CV, certificats et qualifications, photos et descriptifs de projets, accords clients sur la citation. La fiche validée dans la bibliothèque fait foi, jamais l’ancien dossier.
Le contrôle humain: Le chef de projet concerné valide chaque fiche avant intégration : rôle tenu, montants, dates. Le dirigeant valide le droit de citer chaque client, car cette citation engage la relation.
Le résultat attendu: Les preuves se retrouvent sans fouiller d’anciens dossiers et disent la même chose partout. Réponses, propositions et pages du site s’appuient sur des faits vérifiés et à jour.
Quand ne pas le construire: Quand l’entreprise n’a qu’une poignée de références, toutes connues de l’équipe : un dossier partagé bien nommé suffit.
Exemple: Exemple type : une agence d’architecture classe ses projets livrés par typologie, montant et rôle tenu, avec les attestations correspondantes. Pour une nouvelle candidature, l’équipe filtre les références pertinentes et récupère des pièces prêtes à joindre.

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.

Synchronisation des outilsLa synchronisation des outils est l’ensemble des flux qui font circuler une donnée entre CRM, ERP, facturation et outils métier, à partir d’une source de vérité désignée.

Le problème traité: La même information est saisie dans plusieurs outils, avec des versions qui divergent. Les exports et imports manuels se multiplient, le reporting prend des jours et personne ne sait quel chiffre est le bon.
Comment il fonctionne: Pour chaque donnée, on désigne un outil propriétaire et des identifiants stables partagés. Les flux passent par API ou webhooks, via un orchestrateur ou une base intermédiaire (par exemple Postgres). Chaque flux est idempotent, journalisé et surveillé : une erreur crée une alerte et une reprise possible, pas une incohérence silencieuse.
Les données nécessaires: Inventaire des outils et de leurs données, identifiants clients et articles, accès aux API. Une matrice indique, donnée par donnée, quel outil fait foi et lesquels se contentent de lire.
Le contrôle humain: Le DAF et le directeur commercial valident ensemble la matrice des sources de vérité. Un référent traite chaque jour les alertes de synchronisation : une erreur ignorée finit en facture fausse.
Le résultat attendu: Une donnée est saisie une fois et se retrouve juste partout. Les ressaisies disparaissent, les écarts entre outils deviennent des alertes traitées, et le reporting part d’une base cohérente.
Quand ne pas le construire: Quand un seul outil couvre déjà le besoin, ou quand les outils vont être remplacés à court terme : on synchronise un système stable, pas un système en transition.
Exemple: Exemple type : une PME industrielle enregistre une commande dans le CRM, puis la ressaisit dans l’ERP et dans l’outil de facturation. La signature crée désormais le client et la commande dans l’ERP avec le même identifiant, et toute erreur génère une alerte.

Reporting et pilotageLe reporting de pilotage est un jeu restreint d’indicateurs, calculés automatiquement depuis les sources de vérité, qui sert à prendre des décisions à date fixe.

Le problème traité: Chaque comité de direction commence par une consolidation manuelle de tableurs. Les chiffres arrivent tard, divergent selon qui les produit, et les tableaux de bord existants sont consultés sans jamais déclencher de décision.
Comment il fonctionne: On part des décisions récurrentes de la direction, puis on remonte aux indicateurs qui les éclairent, chacun avec une définition écrite, une source et un responsable. Les données sont extraites automatiquement, consolidées dans une base et présentées dans un tableau de bord sobre. Les écarts au seuil déclenchent une alerte.
Les données nécessaires: CRM pour le commercial, ERP ou comptabilité pour le chiffre d’affaires et la marge, outils de production pour l’activité. Chaque indicateur a une source unique documentée ; aucun chiffre n’est ressaisi à la main.
Le contrôle humain: Le dirigeant valide la liste des indicateurs et leurs définitions. Chaque responsable commente les écarts de son périmètre avant le comité : le chiffre est automatique, l’interprétation reste humaine.
Le résultat attendu: Le comité de direction démarre avec des chiffres déjà consolidés et partagés. Le temps passe sur les écarts et les décisions, plus sur la vérification des tableaux.
Quand ne pas le construire: Quand les données sources ne sont pas fiables : automatiser un mauvais chiffre le rend seulement plus rapide et plus crédible qu’il ne devrait l’être.
Exemple: Exemple type : une ETI de services B2B consolide chaque mois ses chiffres à partir de plusieurs tableurs. On retient un petit nombre d’indicateurs liés aux décisions du comité, alimentés automatiquement depuis le CRM et la comptabilité, avec alerte en cas d’écart.

Outils internes ciblésUn outil interne ciblé est une petite application construite pour un usage précis de l’entreprise, lorsque ni le tableur ni le logiciel du marché ne conviennent.

Le problème traité: Un processus critique tourne sur un tableur partagé devenu fragile, ou sur un logiciel générique qui impose des contournements. Les erreurs s’accumulent et tout repose sur la personne qui connaît le fichier.
Comment il fonctionne: On délimite un usage unique et ses utilisateurs, puis on construit l’interface minimale : formulaires, vues, droits, règles de contrôle. L’outil s’appuie sur une base de données propre, reliée aux outils existants. Il est livré vite, utilisé en conditions réelles, puis ajusté. Le code et la documentation appartiennent à l’entreprise.
Les données nécessaires: Données aujourd’hui portées par le tableur ou les e-mails, règles métier implicites à formaliser, liste des utilisateurs et de leurs droits. La base de l’outil devient la source de vérité de ce périmètre.
Le contrôle humain: Un responsable métier est propriétaire de l’outil : il valide les règles, priorise les évolutions et décide de ce qui n’y entre pas. Sans propriétaire, un outil interne redevient vite un tableur.
Le résultat attendu: Le processus repose sur des règles explicites plutôt que sur une personne. Les erreurs de saisie sont bloquées à la source, et l’information devient partagée, traçable et maintenable.
Quand ne pas le construire: Quand un logiciel du marché couvre l’essentiel du besoin, ou quand personne en interne ne peut être propriétaire de l’outil dans la durée.
Exemple: Exemple type : une entreprise industrielle suit ses commandes spéciales dans un tableur partagé entre commerce, méthodes et production. Un outil interne remplace le fichier : chaque commande a un statut, un responsable, des contrôles de saisie et un historique.

6 systèmes

IA encadrée

Des modèles qui travaillent sur vos sources, dans des limites écrites.

Base de connaissance gouvernéeUne base de connaissance gouvernée est un ensemble de documents de référence identifiés, à jour et attribués à des propriétaires, utilisable par les équipes comme par l’IA.

Le problème traité: Le savoir de l’entreprise est dispersé entre serveurs, boîtes e-mail et têtes des experts. Les mêmes questions reviennent, les réponses varient selon la personne, et toute IA branchée dessus reproduit le désordre.
Comment il fonctionne: On identifie les documents qui font foi, on écarte les doublons et les versions obsolètes, puis on structure : nommage, métadonnées, statut, propriétaire, date de revue. Les droits d’accès suivent ceux de l’entreprise. Des revues périodiques maintiennent la base ; la recherche et les usages IA viennent ensuite, sur cette fondation.
Les données nécessaires: Procédures, modèles, notes techniques, documentation produit, réponses types, répartition des responsabilités. Seuls les documents au statut « validé » font foi ; les autres restent consultables mais signalés comme non vérifiés.
Le contrôle humain: Chaque domaine a un propriétaire métier qui valide l’entrée, la mise à jour et le retrait de ses documents. C’est lui, et non l’outil, qui décide de ce qui fait foi.
Le résultat attendu: Les équipes trouvent la version en vigueur sans demander à un collègue. L’intégration des nouveaux arrivants s’appuie sur des sources fiables, et les usages IA disposent d’une base saine.
Quand ne pas le construire: Quand personne ne peut être nommé propriétaire des contenus : une base sans gouvernance redevient un simple dossier partagé en quelques mois.
Exemple: Exemple type : une ETI de distribution B2B conserve plusieurs versions de chaque procédure sur des serveurs différents. On retient une version par procédure, on lui attribue un propriétaire et une date de revue, puis on archive le reste.

Recherche sourcée (RAG)La recherche sourcée (RAG) est un dispositif où un modèle de langage répond uniquement à partir de documents internes retrouvés pour la question, et cite ces documents.

Le problème traité: Retrouver une information suppose de connaître le bon dossier, le bon nom de fichier ou le bon collègue. Un modèle de langage utilisé seul, sans accès aux documents, répond avec assurance et peut inventer.
Comment il fonctionne: Le RAG (retrieval-augmented generation) fonctionne en deux temps : retrouver, puis répondre. Les documents sont découpés et indexés. À chaque question, le système retrouve les passages pertinents, les transmet au modèle avec la consigne de ne répondre qu’à partir d’eux, et affiche la réponse avec ses sources. Sans source suffisante, il répond qu’il ne sait pas.
Les données nécessaires: Une base de connaissance gouvernée, avec droits d’accès et statut de chaque document. Les documents validés font foi ; l’index n’est qu’une copie de travail, reconstruite à chaque mise à jour des sources.
Le contrôle humain: L’utilisateur vérifie la source citée avant de réutiliser une réponse dans un document engageant. Un référent revoit chaque mois les questions restées sans réponse ou jugées fausses, et complète la base.
Le résultat attendu: Les équipes obtiennent une réponse sourcée au lieu de fouiller des arborescences. Chaque réponse est vérifiable, et les lacunes de la base deviennent visibles.
Quand ne pas le construire: Quand les documents sources sont peu nombreux, mal tenus ou contradictoires : le RAG reproduirait ces défauts. Il faut d’abord une base gouvernée.
Exemple: Exemple type : dans une AMO, un chef de projet demande quelles pénalités de retard ont été retenues sur des marchés de travaux comparables. Le système retrouve les clauses dans les dossiers archivés et répond en citant chaque document et son article.

Assistant interne encadréUn assistant interne encadré est un outil conversationnel limité à un métier et à des sources définies, qui prépare un travail que l’utilisateur relit et valide.

Le problème traité: Les équipes utilisent des IA grand public sans cadre : données confidentielles copiées dans des outils externes, réponses non sourcées, pratiques différentes d’une personne à l’autre. Ou bien elles n’utilisent rien, faute d’outil autorisé.
Comment il fonctionne: L’assistant est configuré pour un usage précis : consignes, ton, formats de sortie, sources autorisées via la recherche sourcée. Il n’agit sur aucun système ; il produit des brouillons, synthèses ou réponses. Les échanges sont journalisés, les données restent dans un environnement maîtrisé, et les retours des utilisateurs servent à l’ajuster.
Les données nécessaires: Base de connaissance du métier concerné, modèles de documents, exemples de bons livrables, règles de confidentialité. Les documents validés font foi ; l’assistant ne s’y substitue jamais.
Le contrôle humain: L’utilisateur reste auteur de ce qui sort : il relit, corrige et valide chaque production avant tout usage externe. Le responsable métier valide les consignes de l’assistant et revoit ses écarts chaque mois.
Le résultat attendu: Les tâches de préparation prennent moins de temps, sur des sources contrôlées. L’usage de l’IA devient cadré, homogène et visible, au lieu d’être dispersé dans des outils personnels.
Quand ne pas le construire: Quand l’usage est trop vague pour être décrit en une phrase, ou quand un outil d’IA généraliste, encadré par des règles d’usage claires, couvre déjà le besoin.
Exemple: Exemple type : l’administration des ventes d’une PME de distribution reçoit des questions récurrentes sur les délais et les conditions. L’assistant prépare une réponse à partir des conditions générales et des fiches produit ; le collaborateur la vérifie et l’envoie.

Agent encadréUn agent encadré est un système d’IA autorisé à exécuter un petit nombre d’actions définies dans les outils de l’entreprise, avec permissions explicites, journal et validation humaine.

Le problème traité: Certaines tâches enchaînent lecture, décision simple et action dans plusieurs outils. Un workflow figé ne gère pas leur variabilité, mais une IA libre d’agir crée un risque disproportionné.
Comment il fonctionne: On liste les actions permises (lire, vérifier, préparer un brouillon) et on interdit tout le reste. Chaque action passe par des accès limités et est journalisée. Avant toute action irréversible (envoi, paiement, suppression, engagement), l’agent s’arrête et demande une validation. Il démarre en mode observation, sur un périmètre réduit, avant tout élargissement.
Les données nécessaires: Accès en lecture aux sources nécessaires, écriture limitée aux brouillons, règles métier écrites, historique de cas traités pour l’évaluation. Les systèmes métier restent la source de vérité ; l’agent n’en détient aucune.
Le contrôle humain: Un responsable désigné valide chaque action irréversible avant exécution et revoit le journal chaque semaine. La direction fixe le périmètre : tout élargissement des permissions est une décision écrite, pas un réglage.
Le résultat attendu: Une tâche variable et répétitive est prise en charge jusqu’au point de décision, avec un journal complet. L’humain intervient moins souvent, mais toujours là où l’action engage l’entreprise.
Quand ne pas le construire: Le plus souvent. Si un workflow à règles fixes ou un assistant suffit, l’agent ajoute du risque et de la maintenance sans valeur supplémentaire.
Exemple: Exemple type : chez un distributeur industriel, un agent lit les commandes reçues par e-mail, vérifie références et tarifs, puis crée des brouillons de commande dans l’ERP. Il n’a aucun droit de validation : un gestionnaire contrôle et confirme chaque commande.

Analyse documentaireL’analyse documentaire est l’extraction, par un modèle de langage, d’informations précises dans des documents longs ou hétérogènes, pour les rendre comparables et vérifiables.

Le problème traité: Contrats, factures, rapports ou pièces techniques sont lus un par un pour en extraire quelques informations. Le travail est lent, monotone et sujet aux oublis, surtout sur de gros volumes.
Comment il fonctionne: On définit une grille d’extraction : champs attendus, formats, règles de validité. Le modèle lit chaque document, remplit la grille et indique pour chaque valeur le passage d’origine. Les valeurs incertaines ou hors règles sont signalées. Le résultat alimente un tableau ou une base.
Les données nécessaires: Documents sources (PDF, scans, fichiers bureautiques), grille d’extraction validée, échantillon annoté à la main pour mesurer la fiabilité. Le document original fait toujours foi, jamais la valeur extraite.
Le contrôle humain: Un collaborateur vérifie toutes les valeurs signalées comme incertaines et un échantillon des autres. Le responsable métier valide la grille et fixe le niveau de contrôle selon l’enjeu.
Le résultat attendu: La lecture répétitive laisse place à une vérification ciblée. Les informations clés deviennent comparables d’un document à l’autre, et chaque valeur reste rattachée à sa source.
Quand ne pas le construire: Quand les documents sont peu nombreux, ou quand l’information existe déjà sous forme structurée dans un logiciel : on l’exporte, on ne la relit pas.
Exemple: Exemple type : une direction financière doit recenser durées, reconductions tacites et préavis dans l’ensemble de ses contrats fournisseurs. L’analyse produit un tableau sourcé ; le juriste vérifie les cas signalés et les échéances proches.

Contrôle des exigencesLe contrôle des exigences est la vérification systématique qu’un document de réponse couvre chaque exigence d’un cahier des charges, avec l’endroit précis où elle est traitée.

Le problème traité: Dans les dossiers longs, une exigence oubliée ou une pièce manquante peut disqualifier une offre entière. La relecture finale se fait sous pression, à la main, et repose sur la vigilance d’une ou deux personnes.
Comment il fonctionne: Un modèle de langage extrait les exigences des pièces du marché dans une matrice : exigence, source, caractère éliminatoire. Le système confronte ensuite le projet de réponse à cette matrice et indique, pour chaque ligne, couverte, partielle ou absente, avec le passage correspondant. Les écarts alimentent une liste d’actions avant dépôt.
Les données nécessaires: Pièces du marché (règlement de consultation, cahier des charges, annexes), projet de réponse, liste des pièces exigées. Les pièces du marché font foi ; la matrice extraite est relue avant tout contrôle.
Le contrôle humain: Le responsable de l’offre valide la matrice des exigences dès l’extraction, puis chaque écart signalé. La décision de déposer reste humaine : l’outil peut manquer une exigence implicite ou mal formulée.
Le résultat attendu: Les omissions sont repérées avant le dépôt, pas après. La relecture finale porte sur les écarts identifiés plutôt que sur une vérification exhaustive à la main.
Quand ne pas le construire: Quand le cahier des charges est court et la réponse standard : une checklist relue par une seconde personne suffit.
Exemple: Exemple type : un bureau d’études prépare un mémoire technique pour un marché de maîtrise d’œuvre. La matrice issue du règlement de consultation et du CCTP signale une exigence sans réponse et une attestation manquante ; l’équipe complète avant dépôt.

Comment les outils sont choisis.

Seulement les familles réellement utilisées dans les cas publiés. Chaque choix a une raison, une limite et une porte de sortie : QORAM ne vend pas de logiciel et n’a aucun intérêt à vous enfermer.

Outils utilisés dans les systèmes publiés sur ce site
Famille	Utilisé dans	Pourquoi	Quand on ne le choisit pas	Comment on en sort
Orchestration des workflows	n8n Cloud (FIXIA, L’Architecte ERP)	Workflows lisibles, versionnés, reprises et journal d’exécution, connecteurs nombreux.	Logique métier très lourde ou volumes élevés : du code dédié est préférable.	Les workflows s’exportent ; la logique critique vit en base, pas dans l’outil.
Base de données et source de vérité	Supabase Postgres (FIXIA, L’Architecte ERP, ce site)	Postgres standard, contraintes d’unicité, fonctions et sécurité au niveau des lignes.	Quand le CRM existant du client peut porter la source de vérité.	Postgres s’exporte et se réhéberge ailleurs sans réécriture.
Hébergement web	Vercel (ce site)	Pages générées ou rendues côté serveur, déploiements par prévisualisation, retour arrière immédiat.	Contraintes d’hébergement imposées par le client ou par un cahier des charges.	Next.js est open source et s’héberge sur d’autres infrastructures.
Modèles de langage	OpenAI via API (qualification L’Architecte ERP ; tests FIXIA)	Sortie JSON stricte, coût par appel, qualité suffisante pour la qualification encadrée.	Données qui ne peuvent pas quitter l’entreprise sans cadre contractuel validé.	Le modèle est un paramètre : prompts versionnés, sorties validées par schéma, fournisseur remplaçable.
Mesure de la recherche	Google Search Console (sites de la direction)	Requêtes réelles, indexation, erreurs : la seule source directe sur Google.	Jamais seule : la mesure qui compte est la demande qualifiée, pas le clic.	Données exportables, propriété au nom du client.

Contrôle humain commun à tous les outils : les décisions sensibles restent humaines, chaque action automatisée est journalisée, et les accès sont au nom du client. Données, sécurité et conformité

Réponses directes.

QORAM est-il une agence IA ?

Non. L’IA est une capacité au service de la croissance et du fonctionnement de l’entreprise, utilisée quand elle crée un levier mesurable.

Faut-il construire un agent autonome ?

Rarement. Un workflow, une règle ou un assistant validé par un humain crée souvent plus de valeur avec moins de risque.

Par quel cas d’usage commencer ?

Un cas fréquent, mesurable, structuré, dont l’erreur est visible et réversible. On le fait tourner en observation avant de lui confier quoi que ce soit.

Comment mesurer le retour ?

Temps gagné, erreurs évitées, délai, capacité créée ou conversion, comparés à une mesure de départ prise avant le projet.

Que deviennent nos données ?

Elles restent dans des outils au nom de l’entreprise ; les données personnelles sont masquées avant envoi à un modèle quand c’est possible. Le détail est sur la page données et sécurité.

Un cas d’usage IA à vérifier avant d’investir ?

Trente minutes pour le passer à la grille des six conditions.

Demander un échange de 30 min Lire la méthode

Des systèmes qui tiennent en production, avec l’IA là où elle se mesure.

Six conditions avant tout projet d’IA.

Un cas d’usage à impact

Des données disponibles

Un niveau de risque connu

Une supervision définie

Un coût actuel mesuré

Un gain mesurable

Quatre niveaux d’autonomie. On monte un niveau à la fois.

Règles, sans IA

IA en observation

IA assistée

Agent encadré

Croissance et distribution

Système commercial

Opérations

IA encadrée

Comment les outils sont choisis.

Réponses directes.

QORAM est-il une agence IA ?

Faut-il construire un agent autonome ?

Par quel cas d’usage commencer ?

Comment mesurer le retour ?

Que deviennent nos données ?

Un cas d’usage IA à vérifier avant d’investir ?

QORAM est-il une agence IA ?

Faut-il construire un agent autonome ?

Par quel cas d’usage commencer ?

Comment mesurer le retour ?

Que deviennent nos données ?

Un cas d’usage IA à vérifier avant d’investir ?