IA d’entreprise bâtie sur notre propre technologie, déjà en exploitation
On ne part pas de zéro à chaque projet, et on ne livre pas une plateforme que l’équipe du client devrait monter elle-même. Les patrons existent déjà : ils se déploient et s’intègrent sur les systèmes que l’organisation possède déjà, sans remplacer le core, l’ERP ni le système d’enregistrement.
Notre propre technologie grandit à chaque déploiement
Chaque composant déployé fait désormais partie de notre propre technologie. Le projet suivant ne le reconstruit pas : il le configure. C’est pourquoi le patron de maintenance prédictive est passé de la flotte de véhicules à l’équipement industriel sans être réécrit, et c’est pourquoi le moteur de scoring tourne aujourd’hui sur six domaines qui ne se ressemblent pas entre eux — ce qui change d’un client à l’autre, c’est la table des poids, pas le moteur.
C’est ce qui sépare cela d’un développement sur mesure et d’une licence de logiciel : il n’y a pas de projet qui parte d’une page blanche, et il n’y a pas de produit que l’équipe du client doive intégrer par ses propres moyens. L’intégration est la nôtre.
Auditable par construction, non par ajout
L’équipe s’est formée dans la banque et dans des secteurs régulés. Ce n’est pas un argument de présentation : c’est ce qui décide comment on construit. Dans une banque, un chiffre qu’on ne peut pas expliquer ne sert à rien, aussi exact soit-il.
Le modèle traduit ; le moteur décide.
Un moteur d’inférence déterministe résout sur des règles explicites et versionnées. Le modèle apporte la langue, pas le contenu : il n’est à l’origine d’aucun chiffre.
Derrière chaque affirmation il y a une trace de dérivation.
Quelle donnée est entrée, quelle règle a été appliquée, qui l’a approuvée et depuis quand elle est en vigueur.
La logique ne vit pas dans un prompt.
Elle vit dans des règles datées et dans des procédures de la base de données elle-même, où elle peut se lire, se versionner et se discuter des années plus tard.
La donnée réglementée n’a pas à sortir du réseau.
L’inférence s’exécute sur des serveurs que le client désigne lorsque sa politique de données l’exige.
Ce que l’architecture garantit
Sept décisions prises avant d’écrire la première ligne. Ce ne sont pas des limitations en attente d’être levées : c’est la posture avec laquelle on construit, et elle ne se négocie pas au cas par cas.
Ils ne remplacent ni le core ni les systèmes d’enregistrement.
Ils s’intègrent par lecture ou par interface. Aucun de ces composants n’est la source d’une donnée : la source demeure le système qui la gère déjà.
Le modèle n’est à l’origine d’aucun chiffre.
Tout montant, solde, date et statut provient du système d’enregistrement. Le composant les transporte et les explique ; il ne les calcule pas et ne les reformule pas. Là où un modèle propose un ajustement sur un chiffre, l’ajustement est consigné comme tel, séparé du chiffre de base, avec son origine et avec une pénalité de confiance, et il n’entre pas en vigueur sans qu’une personne l’accepte.
Aucune vanne d’exécution automatique n’est livrée ouverte.
Cette capacité s’active par classe d’opération et par seuil, avec autorisation écrite, et seulement après une période en mode recommandation. La séquence n’est pas négociable : on mesure d’abord contre le jugement humain, on automatise ensuite.
Ils ne prennent aucune décision à conséquence réglementaire sans trace.
S’il est impossible de montrer quelle donnée est entrée, quelle règle a été appliquée et qui l’a révisée, la décision n’est pas émise. Le composant redemande, escalade vers un humain ou admet qu’il ne sait pas.
Aucune biométrie.
L’analytique vidéo est anonyme et agrégée : sans reconnaissance faciale, sans identification de personnes et sans analyse des émotions. C’est une posture de conception, pas une limitation technique qu’on lève sur demande.
Ils n’obligent pas à envoyer la donnée réglementée vers une API externe.
Là où la politique du client l’exige, l’inférence s’exécute sur des serveurs qu’il désigne, avec des modèles à poids ouverts. Ce qui conditionne, en revanche, c’est la capacité de calcul disponible, qui se dimensionne au préalable.
Ils ne se substituent pas au responsable.
La signature, l’approbation et la décision finale restent là où elles sont aujourd’hui. Ces composants préparent, ordonnent et expliquent ; le jugement et la responsabilité ne se transfèrent pas.
Cinq couches au-dessus des systèmes déjà en exploitation
Chaque couche consomme ce que produit la précédente. Aucune ne touche au système source au-delà de la lecture.
Systèmes et canaux du client — aucun n’est remplacé
ERP · core · CRM · référentiel documentaire · vidéosurveillance · portail · WhatsApp
Connecteurs : API · exports planifiés (SFTP / courriel) · RPA · MCP
Compréhension
Ingestion et classification documentaire · Récupération avec citation · Déduplication multi-signal · Vision par ordinateur
Analyse
Consolidation financière · Trésorerie · Prévision · Anomalies · Planification des stocks · Maintenance prédictive
Décision
Moteur d’inférence déterministe · Règles versionnées · Trace de dérivation · Moteur de scoring · Orchestration d’agents · Évaluation et audit
Livraison
Canaux conversationnels · App de terrain · Répartition · Notifications · Portail libre-service · Tableaux de bord en temps réel
Infrastructure
Routage de l’inférence selon la sensibilité · Isolation multi-locataire · File de travaux concurrente · Observabilité et alertes proactives
Vingt-sept composants en six familles
L’ordre n’est pas d’importance mais de dépendance : les premières familles produisent la donnée que les suivantes consomment.
Documents et connaissance
Les pièces qui transforment le papier, les fichiers et le courriel en quelque chose de consultable. C’est là que commence habituellement un premier projet, parce que le volume est élevé et que l’erreur est peu coûteuse à détecter.
Données, finances et intégration
La partie la moins spectaculaire et celle qui conditionne le plus le reste. Le goulot d’étranglement de ces projets n’est presque jamais le modèle : c’est de sortir la donnée du système source avec une autorisation, une qualité et une fréquence suffisantes.
Modèles sur la donnée du client
Les cinq composants qui apprennent de l’historique ou du signal du client lui-même. Le schéma est le même dans tous les cas ; ce qui change, c’est le calibrage contre la donnée de l’organisation, qui se fait avant leur mise en exploitation.
Décision et orchestration
Ce qui sépare une démonstration d’un système qui passe l’audit. Ces cinq composants ne produisent pas de contenu : ils fixent qui décide, avec quelle règle, et comment on prouve ensuite que la décision était la bonne.
Opération, canaux et infrastructure
Par où sort la réponse, qui la reçoit et où tourne le calcul. Ce sont les décisions qu’un client laisse habituellement pour la fin et qui, en pratique, conditionnent quels cas d’usage sont seulement possibles.
Infrastructure
Trois pièces transversales qui ne se voient pas dans une démonstration et sans lesquelles aucune des précédentes ne passe une revue de sécurité.
Le menu complet, composant par composant
La fiche de référence détaille les vingt-sept composants avec ce que chacun résout, ainsi que les plateformes en propre qui appuient l’inventaire. Écrivez-nous et nous vous l’envoyons.
Voir le menu completPrêt à en discuter ?
Si vous évaluez une solution d'IA pour votre entreprise ou souhaitez explorer un partenariat, un associé directeur vous répondra en moins de 24 heures.