Pourquoi nous avons conçu RakerOne de cette façon
La plupart des entreprises intègrent l'IA sur des systèmes hérités conçus pour le stockage, et non pour l'intelligence. Nous avons entièrement reconstruit : données structurées, gouvernance intégrée et interfaces qui éliminent l'assemblage cognitif. Voici pourquoi l'architecture est plus importante que les modèles.

Rédigé par
Pascal Hebert
Perspectives
13 janv. 2026
Lecture de 4 minutes
La plupart des implémentations d'IA échouent parce qu'elles sont construites sur des systèmes conçus pour le stockage, non pour l'intelligence. La contrainte ne réside pas dans le modèle, mais dans l'architecture. Lorsque nous avons conçu RakerOne, nous sommes repartis de zéro.
La plupart des entreprises ajoutent une couche d'IA sur des systèmes qui n'ont jamais été conçus pour elle. Chatbots à l'intérieur des CRM. Résumeurs dans le stockage de documents. Moteurs de recommandation à côté des ERP. Ça se montre bien. Mais cela ne change pas la manière dont le travail se réalise. Les flux de travail restent rigides. Les données restent fragmentées. Les humains traduisent toujours l'intention commerciale en étapes logicielles. La gouvernance intervient toujours après l'exécution au lieu de pendant. C'est pourquoi la plupart des initiatives en IA stagnent. La contrainte n'est pas le modèle, c'est l'architecture.
Lorsque nous avons créé RakerOne, nous avons commencé par une question : Si nous concevions un système d'exploitation aujourd'hui, sachant que l'IA existe, que ne construirions-nous plus à l'ancienne ?
Rendre les données natives pour IA
Les données d'entreprise sont désordonnées, non pas parce que les organisations sont négligentes, mais parce que les systèmes hérités ont été construits pour le stockage et le rapport, pas pour le raisonnement.
Les ERP stockent les transactions. Les CRM stockent les interactions. Les documents sont conservés dans des dépôts. Aucun n'a été conçu pour l'intelligence. Poser un LLM dessus, et vous obtenez des réponses astucieuses. Pas une exécution fiable.
C'est pourquoi nous avons créé RakerOne avec deux fondations de données travaillant ensemble.
1) BakedB : IA-Natif dès le départ
Tout ce qui est créé à l'intérieur de RakerOne (ensembles de données, flux de travail, tâches, décisions, approbations) vit dans BakedB, notre base de données propriétaire conçue pour l'intelligence, pas le stockage. Les données ne sont pas enregistrées comme des lignes et des colonnes, elles sont structurées comme des entités avec des relations intégrées, des règles commerciales et des autorisations.
2) Plan de données virtuel : Convertir l'héritage en intelligence
Vos systèmes existants n'ont pas été conçus pour l'IA. Le Plan de données virtuel corrige cela sans devoir tout remplacer. C'est une couche de schéma qui se place au-dessus de vos ERP, CRM, dépôts de documents et outils opérationnels. Au lieu de déplacer les données, il redéfinit la façon dont l'IA les comprend :
Les entités deviennent explicites
Les relations sont définies à travers les systèmes
Les règles commerciales sont encodées structurellement
Les autorisations se lient aux actions, pas seulement aux données
Un client n'est pas juste un enregistrement CRM, il est connecté aux contrats, aux revenus, aux tickets de service, à l'exposition réglementaire, à l'historique des paiements, à la marge, à la probabilité de renouvellement. Un contrat n'est pas un PDF, c'est un objet structuré avec des clauses, des plafonds de responsabilité, des obligations, des déclencheurs d'escalade, des limites d'approbation.
Sans structure, l'IA devine. Avec structure, l'IA opère.
Éliminer l'exposition sécuritaire persistante
Un des plus grands risques dans l'adoption de l'IA ? L'exposition directe des systèmes.
La plupart des intégrations donnent aux modèles un accès direct en écriture, répliquent les données dans des bases de données IA persistantes, ou créent des copies fantômes qui dérivent hors synchronisation. Les trois augmentent la surface d'attaque. Dans les industries réglementées, c'est inacceptable.
Notre approche : l'IA opère à l'intérieur d'une couche d'exécution éphémère et contrôlée. Les données se rassemblent lorsque nécessaire, la tâche s'exécute dans les limites de gouvernance, les résultats se valident, puis la couche temporaire se dissout.
Aucune base de données IA permanente ne contient l'état opérationnel sensible. Chaque session est isolée, contextuelle, limitée dans le temps. Ce que les attaquants exploitent, c'est la persistance. Nous l'éliminons.
Les permissions, les politiques et les contraintes de rôle sont encodées structurellement. L'IA ne peut dépasser le périmètre défini. Les écritures nécessitent une validation par les règles de gouvernance et, si nécessaire, des points de contrôle humains.
Résultat : l'IA comprend vos données sémantiquement, opère dans des frontières de permission strictes et ne devient jamais un vecteur d'attaque permanent.
Contexte plutôt que invites
Nous ne voulions pas que l'IA suggère des choses dans une fenêtre latérale. Nous voulions qu'elle exécute dans des flux de travail gouvernés.
Dans un amendement de bail, le système reconnaît le contexte. Lors de l'examen d'une réclamation, il comprend l'exposition politique. Lors du traitement d'une soumission réglementaire, il applique une validation structurée.
Pas par des invites. Par des fonctions contextualisées liées au système d'exploitation lui-même. L'intention est déduite d'où vous êtes et de ce que vous faites, pas saisie dans une boîte de chat.
Éliminer l'assemblage cognitif
Considérez la planification des ressources dans un système hérité : Ouvrez l'ERP, naviguez jusqu'à la planification, créez un rapport, ajustez les vues, ajustez les filtres, ajustez les dates, vérifiez la disponibilité, réconciliez les écarts. Plusieurs systèmes. Interprétation manuelle. Vous assemblerez du sens à partir de données.
L'IA basée sur conversation améliore cela. Tapez « Montrez-moi l'exposition des ressources du prochain trimestre dans le secteur de la santé », obtenez un paragraphe ou un tableau. Plus rapide, mais incomplet. Vous devez toujours lire, interpréter, vérifier, ouvrir un autre onglet, ajuster manuellement les allocations. La conversation réduit la navigation. Elle n'élimine pas l'assemblage cognitif.
RakerOne comble cette lacune par le biais de l'UI Générative. La même demande ne génère pas de texte, elle génère la surface opérationnelle correcte :
Calendrier de planification en direct
Cartes de chaleur d'occupation
Drapeaux de sur-attribution
Filtres de compétences
Simulation d'impact sur la marge
Aucune interprétation requise. Aucun passage du texte à l'action. L'interface devient contextuelle.
Un autre exemple, la santé client :
Héritage : Tire des rapports CRM, exporte les tendances de revenus, analyse les tickets, scanne les fils d'email, construit une diapositive
IA de conversation : Obtenez une analyse narrative
GenUI : Obtenez un panneau de décision structuré avec score de risque, trajectoire de revenus, fréquence d'engagement, décompte des escalades, probabilité de renouvellement, intervention suggérée
GenUI n'est pas une question d'esthétique. Il s'agit de réduire l'énergie mentale. Lorsque l'IA ne répond qu'en paragraphes, les utilisateurs assemblent le puzzle. L'assemblage est coûteux, il ralentit les décisions, augmente les erreurs, exacerbe la fatigue.
Dans les organisations de taille moyenne, la charge cognitive est invisible mais mesurable. Chaque clic supplémentaire, champ non pertinent, tableau de bord générique ajoute de la friction. GenUI effondre Intent → Interface → Exécution.
Délimitations, pas boîtes noires
Dans les industries réglementées l'IA ne peut fonctionner comme une boîte noire. La gouvernance dans RakerOne est intégrée :
Autorisations basées sur les rôles
Moteurs de politique
Actions traçables
Points de contrôle humain où nécessaire
Chaque action IA existe à l'intérieur de frontières définies. C'est la différence entre l'IA comme assistant et l'IA comme opérateur.
Ce qui arrive ensuite
Vos équipes passent 15 à 20 heures par semaine à traduire entre les systèmes, assembler le contexte, valider les résultats. Ce n'est pas un problème logiciel, c'est un problème d'architecture.
La plupart des organisations essaient de résoudre cela avec de meilleures interfaces, des chatbots plus intelligents, plus d'intégrations. Mais la contrainte n'est pas l'accès à l'information. C'est que les systèmes hérités n'ont jamais été conçus pour l'intelligence. Vous ne pouvez pas ajouter du raisonnement à une infrastructure de stockage. Vous ne pouvez pas ajouter de la gouvernance après l'exécution. Vous ne pouvez pas éliminer l'assemblage cognitif avec de meilleures invites. L'architecture doit changer.
L'IA construite sur une infrastructure héritée vous donne des réponses plus rapides. L'infrastructure IA-native vous donne un levier opérationnel. L'une crée une amélioration graduelle. L'autre multiplie la productivité pour changer les performances.
Les dirigeants du marché intermédiaire qui reconstruisent sur une infrastructure IA-native ne réalisent pas des gains marginaux. Ils éliminent 30 à 40 % du travail opérationnel manuel. Ils atteignent le ROI en mois, pas en années. Ils transforment l'IA d'un outil de productivité en avantage concurrentiel.
La question n'est pas de savoir si ce changement se produit. C'est de savoir si vous le dirigez ou si vous réagissez à celui-ci.




