Avant de connecter l'IA à tous les outils de votre entreprise

Connecter un assistant d'IA aux systèmes de l'entreprise, c'était il n'y a pas si longtemps un projet, et c'est toujours le cas pour une grande majorité d'entreprises qui utilisent des systèmes plus anciens. Pour d'autres, c'est maintenant un paramètre. Claude, OpenAI et d'autres offrent des connecteurs pour les ERP, les CRM, la comptabilité et la gestion de projets. En quelques minutes, n'importe qui peut demander les revenus par mois et obtenir un tableau de bord fonctionnel. C'est réel, et c'est utile.

Cela soulève aussi une question légitime pour toute équipe de direction : si l'IA peut rejoindre chaque système et construire le tableau de bord, où ces outils devraient-ils vivre?

J'utilise Claude tous les jours, branché sur notre comptabilité, notre facturation et notre CRM, et bâtir des plateformes de données, c'est mon métier. Ce texte n'est donc pas un plaidoyer contre la connexion de l'IA à vos outils. Il porte sur la différence entre poser une question une fois et faire rouler une entreprise sur la réponse : ce que cela coûte, si vous pouvez prouver le chiffre, et ce qui arrive aux gens qui n'ouvriront jamais une fenêtre de clavardage.

1. Chaque personne a besoin d'un siège payant, qu'elle construise ou qu'elle consulte

Les connecteurs de Claude fonctionnent avec tous les forfaits, y compris le forfait gratuit. Les contrôles dont une entreprise a besoin, eux, non. Le contrôle administratif des connecteurs et l'authentification unique (SSO) commencent avec le forfait Team, à 20 $ US par siège par mois en facturation annuelle (25 $ US au mois), qui couvre de 2 à 150 sièges. Au-delà de 150 personnes, il faut passer à Enterprise (minimum de 20 sièges). Les journaux d'audit sont offerts seulement avec Enterprise, à 20 $ US par siège plus l'utilisation facturée aux tarifs de l'API. Pour une entreprise de 200 employés, cela représente 48 000 $ US par année en sièges seulement, avant l'utilisation.

Les connecteurs fonctionnent aussi personne par personne. Chez Airtable, un administrateur peut devoir approuver l'intégration, puis chaque utilisateur se connecte avec son propre compte, et Claude n'accède qu'aux données que cet utilisateur a déjà le droit de voir. C'est le bon modèle de sécurité. Cela veut aussi dire que chaque personne qui a besoin d'un chiffre par Claude doit avoir un siège Claude, un siège dans le système source et sa propre connexion.

L'utilisation est rarement uniforme. Dans la plupart des entreprises avec qui nous travaillons, une minorité de personnes utilisent l'IA tous les jours et la majorité, quelques fois par mois. Encore moins de gens construisent. Pour une entreprise de 40 personnes sur Team Standard, les sièges coûtent 9 600 $ US par année. C'est une bonne affaire si 40 personnes construisent avec. C'est une façon coûteuse de donner à 34 personnes l'accès en lecture à un rapport mensuel.

Les sièges ont aussi des limites : une fenêtre d'utilisation glissante de cinq heures, plus des plafonds hebdomadaires. Le travail sur les données est lourd, et au-delà de ces limites, il faut attendre ou payer l'utilisation supplémentaire aux tarifs de l'API.

2. Un modèle d'IA est la calculatrice la plus chère de l'entreprise

Chaque question posée par un connecteur est calculée à partir de zéro. Claude interroge le système source, lit ce qui revient, raisonne et rédige la réponse. Quand un collègue pose la même question demain, tout recommence.

Prenons un de nos clients : plus de 15 millions de lignes de transactions par année. Exportée en JSON, une ligne de dix champs compte environ 80 jetons (tokens) : une seule année de données brutes représente donc environ 1,2 milliard de jetons. Au prix affiché d'Opus 5.5, soit 4 $ US par million de jetons en entrée, les lire une seule fois coûte environ 4 800 $ US, avant tout raisonnement et toute réponse. De toute façon, elles n'entreraient pas : c'est 1 200 fois la plus grande fenêtre de contexte offerte par Claude (section 4).

Un moteur SQL additionne les mêmes 15 millions de lignes en quelques secondes, pour quelques cents tout au plus. C'est cet écart qu'il faut planifier.

La meilleure approche utilise l'IA là où elle excelle et la garde hors de la boucle qui s'exécute chaque jour :

1. Construire avec l'IA, une fois. Claude écrit l'extraction, les jointures et le calcul de la marge. Une personne qui connaît l'entreprise les révise.
2. Exécuter sans IA, selon un horaire. Un pipeline charge seulement ce qui a changé dans un data lake ou un entrepôt de données, puis rafraîchit les tables finales.
3. Lire le résultat. Les tableaux de bord, les rapports et les assistants d'IA interrogent les tables finales, pas la source brute.

Le calcul est alors payé une fois par rafraîchissement, et non une fois par question, par personne.

3. Pouvez-vous prouver comment le chiffre a été calculé?

Un connecteur donne à Claude l'accès à vos données, pas à votre définition de l'indicateur. Demandez la marge brute, et l'IA doit décider à votre place :

• Revenus facturés, constatés ou encaissés?
• Notes de crédit déduites le mois de leur émission, ou le mois de la facture d'origine?
• Quels comptes font partie du coût des ventes?
• Transactions intersociétés éliminées ou non?
• Mois de l'exercice financier ou mois civils?

Chaque choix se défend, et chacun donne un chiffre différent. Ce sont vos règles d'affaires qui font que le chiffre est le vôtre.

Les modèles de langage ne sont pas déterministes non plus. La même question posée deux fois peut produire deux calculs différents. Sur les modèles Claude actuels, les développeurs ne peuvent même plus régler le paramètre de température qui rendait les réponses plus reproductibles. Les modèles sont aussi retirés : Claude Sonnet 4 et Opus 4, lancés en mai 2025, ont été retirés le 15 juin 2026. Le modèle qui a produit le rapport de cette année n'existera peut-être plus quand vous le referez l'an prochain.

Les compétences (skills) et les instructions de projet aident. Vous pouvez écrire la règle de marge et demander à Claude de l'appliquer. Mais une instruction guide le modèle, elle ne lie pas l'utilisateur. N'importe qui peut encore demander de « laisser les notes de crédit de côté cette fois-ci », et le résultat a l'air aussi officiel que le chiffre gouverné.

Puis arrive l'auditeur, le prêteur ou le conseil d'administration : comment avez-vous calculé la marge de cette année, et est-elle calculée de la même façon que l'an dernier? Une réponse défendable a trois parties :

• les données telles qu'elles étaient à ce moment-là;
• la logique exacte qui leur a été appliquée;
• une trace de qui a modifié cette logique, et quand.

Un historique de conversation vous donne, au mieux, une partie de la deuxième. Des transformations écrites sous forme de code versionné, dans un pipeline qui s'exécute toujours de la même façon, vous donnent les trois. L'IA peut quand même écrire ce code. Elle ne devrait simplement pas le réinventer à chaque question.

4. Un résumé entre dans une fenêtre de contexte. Votre ERP, non.

La plus grande fenêtre de contexte de Claude est de 1 million de jetons. C'est beaucoup de texte, plusieurs longs romans. Ce n'est pas beaucoup de transactions : à 80 jetons par ligne, environ 12 000 lignes de facturation, moins ce que la conversation elle-même utilise.

Les connecteurs sont conçus autour de cette limite. Ils retournent de petites réponses : un rapport, une page d'enregistrements, un total que le système source a déjà calculé. Les revenus par mois des 24 derniers mois, ce sont 24 chiffres, et cela fonctionne bien.

Les difficultés commencent avec les questions qui donnent sa valeur à l'analytique. Quels clients glissent vers le départ? Comment la marge évolue-t-elle avec le volume? À quoi ressemblera la trésorerie du prochain trimestre? Ces questions exigent l'historique complet, au niveau de la transaction, souvent croisé entre plusieurs systèmes. Cela n'entre dans aucune fenêtre de contexte.

À ce stade, l'IA ne devrait pas lire les données, elle devrait les interroger. Les données résident dans un data lake ou un entrepôt de données. Claude écrit le SQL, le moteur l'exécute sur des millions de lignes, et seul le résultat revient. Personne dans votre équipe n'a besoin d'écrire du SQL. Mais le SQL, ou un équivalent, est la façon dont l'IA accédera à vos données, les transformera et les modélisera à grande échelle.

Deux limites pratiques s'appliquent avant tout cela :

• Beaucoup de systèmes n'ont pas de connecteur. Les ERP et les bases de données plus anciens installés sur site, les partages de fichiers et les applications maison sont hors de portée.
• Les systèmes sources rationnent leurs API. QuickBooks Online, par exemple, permet 500 requêtes par minute par entreprise, et son serveur MCP n'est toujours pas disponible au Canada au moment d'écrire cet article. Extraire tout l'historique par une API chaque fois que quelqu'un pose une question est lent, et cela entre en concurrence avec les intégrations dont vos opérations dépendent.

5. Quatre risques dont on parle moins

Les permissions ne suivent pas les données

Les bons connecteurs respectent les permissions de l'utilisateur dans le système source. Airtable, par exemple, indique que l'utilisateur n'accède qu'aux données qu'il a déjà le droit de voir ou de modifier. Mais une fois que les chiffres quittent la source, dans un artefact, une exportation ou un tableau collé, ces permissions ne s'appliquent plus. Un contrôleur qui voit les salaires construit un tableau de bord des coûts et partage le lien. Toute personne qui l'ouvre voit maintenant ce que le contrôleur voit. Dans un entrepôt de données, la sécurité par ligne et par colonne s'applique à chaque outil qui lit la table.

Les systèmes sources gardent le présent, pas le passé

La plupart des systèmes opérationnels conservent l'état actuel. Quand une occasion change d'étape, qu'un client passe à un autre représentant ou qu'un budget est révisé, l'ancienne valeur est écrasée. Un connecteur ne peut interroger que le présent. « Les revenus par représentant l'an dernier, tels que nous les avions présentés » exigent des instantanés pris à l'époque. Cet historique n'existe que si quelque chose l'enregistrait.

Les vraies questions touchent plusieurs systèmes

Chaque connecteur voit un seul système. Le système immobilier connaît l'immeuble, l'outil de projets connaît le bon de travail, la comptabilité connaît le coût. Les relier exige des clés communes, et elles concordent rarement : « Tour Est », « TOUR-EST-01 » et la propriété 1042 peuvent désigner le même immeuble. Résoudre cela dans chaque conversation est fragile. Une table de correspondance dans un entrepôt le résout une fois.

La confidentialité est une décision, pas un paramètre

Les données extraites par un connecteur sont envoyées au fournisseur d'IA pour traitement. Sur la plateforme d'Anthropic, l'inférence s'exécute aux États-Unis ou à l'échelle mondiale, et les données au repos sont stockées aux États-Unis. Avec les forfaits Free, Pro et Max de Claude, l'utilisation des conversations pour entraîner de futurs modèles est un paramètre propre à chaque utilisateur. Au Québec, la Loi 25 exige une évaluation des facteurs relatifs à la vie privée avant de communiquer des renseignements personnels à l'extérieur du Québec (article 17 de la Loi sur la protection des renseignements personnels dans le secteur privé). Un connecteur qui lit des dossiers de locataires, d'employés ou de clients est en plein dans le champ d'application.

6. Quand tout le monde peut construire, chaque outil a besoin d'un responsable

Jusqu'à récemment, un tableau de bord, un outil de suivi ou une petite application interne exigeaient des compétences techniques, alors une poignée de personnes les construisaient. Ce goulot était frustrant. Il servait aussi de gouvernance. L'IA l'élimine : n'importe qui peut maintenant bâtir son propre CRM, sa propre analyse financière, son propre calculateur de commissions.

C'est une bonne chose, jusqu'à un certain point. Dix services avec dix définitions de « client actif », c'est le vieux problème des chiffriers, en plus rapide et avec une plus belle interface. Chaque outil soulève aussi les mêmes questions :

• Qui le répare quand un système source renomme un champ?
• Où vivent les données qu'il crée, et sont-elles sauvegardées?
• Qu'advient-il de l'outil quand la personne qui l'a construit quitte l'entreprise?
• Qui forme les autres utilisateurs, et où est la documentation?
• Comment partage-t-on l'accès de façon sécuritaire, avec des journaux d'audit?
• Comment s'assure-t-on qu'il respecte nos normes de cybersécurité?

L'analytique a toujours eu besoin de gouvernance. La réponse n'a pas changé, elle compte simplement plus que jamais :

• Une fondation commune. L'entreprise fournit des jeux de données validés : sources documentées, transformations clairement définies, règles d'affaires testées, rafraîchissements surveillés, permissions appliquées.
• La liberté par-dessus. Tout le monde peut construire et explorer avec l'IA sur ces jeux de données, pas sur des extraits bruts.
• Publier ce qui fonctionne. Les meilleurs outils sont révisés, reçoivent un responsable, puis sont offerts à tous, au lieu de vivre dans le compte d'une seule personne.

7. Tout le monde ne veut pas « prompter »

Des employés de nos clients nous le disent franchement : ils ne veulent pas « prompter ». Ils ne savent pas quoi demander, comment le formuler, ni comment juger si la réponse est bonne. Une boîte de requête vide est une page blanche, et une page blanche, c'est difficile.

Chaque entreprise a des bâtisseurs et des utilisateurs, et les bâtisseurs sont minoritaires : les gens qui aiment le faire, qui comprennent les données et qui en ont le temps. Ils sont à l'aise avec une requête, car ils connaissent la question et savent juger la réponse. Les utilisateurs, eux, ont besoin d'un écran qui s'ouvre sur les bons chiffres, de boutons qui font ce qu'on attend et d'une formation qui tient en une heure.

Un tableau de bord montre aussi le même chiffre à tout le monde, et c'est tout l'intérêt d'un chiffre partagé. Une conversation donne à chacun sa propre version.

L'IA a changé la façon de construire les outils. Elle n'a pas éliminé le besoin d'une interface claire. Tout n'a pas besoin d'être un prompt.

8. Garder la liberté de changer de modèle

Le modèle que vous utilisez aujourd'hui ne restera pas longtemps le meilleur ni le moins cher. Le tableau des retraits d'Anthropic compte six modèles Opus lancés depuis novembre 2025. Les prix varient aussi beaucoup chez un même fournisseur : par million de jetons en entrée, Claude Haiku 5.5 coûte 0,10 $ US, Opus 5.5, 4 $ US et Fable 5.1, 10 $ US.

Cet écart est une occasion. Catégoriser 10 000 lignes de dépenses n'exige pas le même modèle que bâtir une prévision de trésorerie. Confier les tâches routinières à Haiku 5.5 plutôt qu'à Opus 5.5 coûte 40 fois moins cher, et la prochaine version changera peut-être quel modèle convient à quelle tâche. La même logique s'applique d'un fournisseur à l'autre.

La plupart des assistants offrent maintenant un certain choix de modèles. Microsoft 365 Copilot a ajouté les modèles d'Anthropic à côté de ceux d'OpenAI en septembre 2025. Le véritable enfermement, c'est l'endroit où vit le travail. Un tableau de bord construit comme artefact Claude, un GPT personnalisé ou un agent Copilot vit dans ce produit, avec sa logique dans des requêtes et un historique de conversation. Le déplacer, c'est le reconstruire.

Pour rester libre, gardez l'essentiel hors de l'assistant : les données dans votre propre stockage, les règles d'affaires en SQL, et des outils qui lisent les deux. Les standards ouverts aident. Le Model Context Protocol (MCP), qu'utilisent les connecteurs de Claude, a été adopté par ChatGPT, Gemini et Microsoft Copilot, et relève maintenant d'un fonds de la Linux Foundation cofondé par Anthropic, Block et OpenAI. Quand chaque modèle se branche sur les mêmes tables gouvernées, changer de modèle devient un paramètre, pas une migration.

Une architecture qui tient la route

Séparez la construction de l'exécution. Utilisez l'IA pour construire, avec tous les connecteurs nécessaires. Produisez les chiffres dont l'entreprise dépend à partir d'une couche de données gouvernée, rafraîchie selon un horaire, et laissez les gens et l'IA lire les mêmes tables.

L'IA a sa place dans la boucle de construction, pas dans la boucle d'exécution. Une fois la logique écrite et révisée, les rafraîchissements n'ont besoin d'aucun modèle. L'exception : les enrichissements et les analyses qu'un agent produit à partir des tables gouvernées, comme catégoriser des dépenses ou expliquer un écart à même un rapport. L'agent s'exécute alors selon un horaire, ses résultats sont stockés comme n'importe quelle autre table, et chaque outil lit les mêmes chiffres.

Questions à régler avant de tout connecter

• Qui a besoin de construire, et qui a seulement besoin de voir les chiffres?
• Quels indicateurs exigent une définition officielle unique, et où cette définition est-elle écrite en code?
• Pourrions-nous reproduire aujourd'hui les chiffres de l'an dernier, avec la logique utilisée à l'époque?
• Gardons-nous l'historique, ou seulement ce que nos systèmes sources contiennent aujourd'hui?
• Quels renseignements personnels quitteraient le Québec, et l'évaluation des facteurs relatifs à la vie privée a-t-elle été faite?
• Qui est responsable de chaque outil construit, et où les meilleurs sont-ils publiés?
• Si un modèle meilleur ou moins cher sort le mois prochain, que faudrait-il pour changer?

Les connecteurs sont un vrai pas en avant. Utilisez-les pour explorer, prototyper et répondre aux questions ponctuelles, et utilisez l'IA pour construire. Puis placez les chiffres qui font rouler votre entreprise à un endroit où ils sont calculés une fois, conservés dans le temps et calculés de la même façon pour tout le monde.

Divulgation : je suis le fondateur de BEEM, une plateforme de données et d'IA conçue pour cette couche de fondation. Je passe mes journées à orchestrer des agents directement dans Claude, toute notre équipe l'utilise de façon intensive, et comme PME, nous vivons ces enjeux tous les jours. Je ne les constate pas seulement chez nos clients de plus grande taille : ils valent tout autant pour les plus petites entreprises. Je vous encourage donc à faire de même : créez et explorez, mais pensez dès le départ à la mise en production à l'échelle de l'organisation. C'est là que se trouve le vrai gain. Les points ci-dessus tiennent, peu importe la plateforme choisie.