bearingbridge intelligence

Non, et dans la plupart des projets rien ne bouge. SL01 lit les comptes et les contacts de votre CRM par son API et réécrit dans les mêmes champs : votre CRM reste la référence pour les clients. Votre ERP reste la référence pour les commandes. DB09 lit les deux et rapporte les lignes où ils divergent, au lieu de désigner un gagnant. La seule chose qui déménage, ce sont les définitions : DB02 les tient en un seul endroit au lieu de trois.

IT01 à IT05, ou DB01 à DB04, pour la même raison dans les deux cas : la référence existe déjà. Votre historique de tickets dit ce que vous coûtent aujourd’hui une réinitialisation de mot de passe, une panne de VPN ou une installation de logiciel, si bien que l’avant et l’après ne se discutent pas. Les tableaux de bord fonctionnent pour la raison inverse : le diagnostic produit en général un constat qui, à lui seul, justifie l’exercice. Commencez par un module, pas quatre.

Vous l’apprenez par écrit, avant toute construction. Constat typique : trois systèmes portent chacun un champ « client actif », l’un compte les comptes d’essai, l’autre exclut les clients partis depuis moins de quatre-vingt-dix jours, et le dossier du comité utilisait en silence celui qui répondait le premier. DB02 le révèle pendant le diagnostic. Si le chantier est lourd, le socle de données se chiffre à part et le module attend. Un module posé sur ce désordre ne le corrigerait pas : il le publierait plus vite.

Pour une action donnée, ne partent vers le fournisseur de modèle retenu que la requête et les enregistrements ou passages dont cette action a besoin. Rien d’autre. Nous n’entraînons rien sur vos données, et aucun autre client ne voit votre espace. Les règles de conservation de chaque fournisseur entrent dans la décision de routage et sont documentées modèle par modèle à la passation : vous pouvez lire précisément quel fournisseur a vu quoi. Quand des règles de résidence imposent qu’un modèle tourne dans une juridiction donnée, cela contraint la table de routage, cela n’ouvre pas une négociation.

Vous, et la passation est concrète : le code dans votre dépôt, la documentation dans votre wiki, la base dans votre compte cloud si vous la voulez là, les variables d’environnement et les identifiants chez votre équipe. La passation est un livrable avec une date, pas une concession de fin de contrat.

Les tokens s’achètent d’avance, sous forme de crédit : rien ne peut se facturer après coup. Chaque action affiche son prix à l’écran pendant qu’elle tourne. Chacun porte un plafond quotidien, l’organisation un plafond mensuel, et au plafond la génération s’arrête tandis que la consultation et les tableaux de bord continuent. La ligne de registre de chaque action enregistre la personne, l’horodatage, l’identifiant du module, le modèle sollicité, les tokens consommés, le coût et, le cas échéant, l’approbateur. Cette ligne s’exporte, et c’est en général ce que la direction financière demande vraiment.

Les deux, et la liste s’écrit module par module. Sous IT05, un client type autorise sans surveillance la réinitialisation d’un mot de passe et la réaffectation d’une licence, et exige un humain pour tout ce qui ouvre un groupe administrateur. Sous CS02, le brouillon se génère seul, l’envoi reste humain. Sous CS14, un message sortant vers un client pour une livraison en retard passe par une approbation sur les cinquante premiers, puis le client décide, en général, d’assouplir ou non. Cette liste se révise, elle ne se fige pas.

Celui qui obtient les meilleurs résultats sur la tâche précise et qui est autorisé là où vous opérez. Nous routons entre fournisseurs occidentaux et chinois : GPT, Claude, Gemini et Llama d’un côté, Qwen, DeepSeek, GLM, Kimi, Doubao et ERNIE de l’autre. Le routage se fait par tâche, pas par client : la classification de tickets va vers un petit modèle bon marché, parce que le travail est une étiquette, et l’extraction de clauses contractuelles vers un modèle plus puissant, parce qu’une date fausse coûte cher. La table est documentée et réévaluée au banc d’essai chaque trimestre.

Le plus souvent oui, et vous obtenez une date, pas une diapositive de feuille de route. Une API REST ou GraphQL documentée : quelques jours, en général. Une interface SOAP ancienne ou une réplique en lecture d’une base sur site : une à deux semaines. L’échange de fichiers plats par SFTP reste la solution de repli quand un système n’offre aucune interface digne de ce nom, et cela fonctionne. Quand la seule voie d’entrée serait de piloter un vieux client lourd écran par écran, nous vous dirons que c’est fragile et le chiffrerons comme tel, ou nous refuserons.

Nous le construisons, et cela coûte plus cher : rien du squelette ne se réutilise, tout est mise en œuvre. La séquence ne change pas : diagnostic, version qui fonctionne sur vos données, consolidation, passation. Dans les faits, environ un tiers des demandes se révèle être un module existant avec d’autres règles : une conversation de paramétrage plutôt qu’une construction neuve, et c’est le diagnostic qui tranche.