Un modèle d'IA ou plusieurs : ce que le multi-modèle coûte vraiment à une PME

La question arrive toujours dans le même ordre. Une PME déploie Copilot parce qu’il est déjà dans le tenant. Six mois plus tard, quelqu’un lit qu’un autre modèle est meilleur pour la rédaction, un troisième pour l’analyse de documents. Et la question tombe : est-ce qu’on devrait en utiliser plusieurs ?

Les comparatifs répondent avec des palmarès et des coûts par million de jetons. C’est la mauvaise réponse, parce que c’est la mauvaise question.

Le vrai coût n’est pas le jeton

Le prix d’appel des modèles baisse continuellement. Ce n’est pas là que le multi-modèle vous coûte de l’argent. Il vous coûte ailleurs, sur quatre postes que les grilles tarifaires ne montrent pas.

Le routage doit être maintenu. Décider quelle requête va vers quel modèle, c’est du code ou de la configuration. Ça vit, ça casse, ça se met à jour quand un fournisseur retire un modèle. Quelqu’un doit posséder ce composant.

L’évaluation double. Vous ne pouvez pas affirmer qu’un modèle est meilleur pour votre cas sans l’avoir mesuré sur vos données. Deux modèles, c’est deux jeux de tests à écrire et à réexécuter à chaque changement de version.

L’inventaire s’allonge. Chaque modèle ajouté est un fournisseur de plus dans le registre que vos obligations vous imposent de tenir : finalités, données en entrée, données en sortie, contrat. Notre billet sur les recommandations de la CAI détaille ce que cet inventaire doit contenir.

La surface de conformité s’élargit. Et c’est le poste le plus mal évalué, pour une raison précise.

Le piège : hébergé au Canada n’est pas traité au Canada

Voici ce que la documentation des fournisseurs dit, et ce que presque personne ne vérifie avant de signer.

Précision de périmètre : si vous n’utilisez que Copilot dans Microsoft 365, vous ne choisissez pas ces paramètres. La question se pose dès que vous branchez un modèle par API ou construisez un agent, c’est-à-dire exactement au moment où le multi-modèle entre en jeu.

Microsoft distingue explicitement le stockage et le traitement pour les modèles servis par Azure. La documentation des types de déploiement, mise à jour en août 2026, est sans ambiguïté : les données au repos restent dans la géographie Azure désignée, mais le lieu de traitement de l’inférence dépend du type de déploiement choisi.

Type de déploiement	Où l’inférence est traitée
Global	N’importe quelle région Azure, dans le monde
Data Zone	Uniquement dans la zone désignée : États-Unis, Union européenne ou Asie-Pacifique
Standard et Regional Provisioned	Dans la géographie Azure choisie, par exemple le Canada

Trois choses à en tirer.

Il n’existe pas de zone de données Canada. Les trois zones offertes sont les États-Unis, l’Union européenne et l’Asie-Pacifique. Pour qu’une requête soit traitée au Canada, il faut un déploiement de type géographique dans une région canadienne, pas une zone.

Le type recommandé par défaut est Global, celui qui peut router n’importe où. La documentation le dit franchement : pour la plupart des charges de travail, commencez par Global Standard. C’est le choix par défaut, et c’est celui qui envoie vos requêtes hors du pays.

Les déploiements géographiques arrivent en dernier. Toujours selon la même page, les nouveaux modèles sortent d’abord en Global, puis en Data Zone, et les types géographiques arrivent après, sans date de disponibilité garantie.

Le portrait est le même ailleurs. AWS a publié en novembre 2025 un billet sur l’inférence interrégionale au Canada qui explique que les données au repos demeurent exclusivement dans la région Canada (Centre), mais que les requêtes d’inférence en provenance du Canada peuvent être acheminées vers des régions américaines selon le profil retenu. Chez Google, la documentation de Vertex AI sépare de la même façon la résidence au repos et le lieu du traitement d’apprentissage machine.

Autrement dit : sur les trois grands nuages, « nos données sont au Canada » et « nos requêtes sont traitées au Canada » sont deux affirmations distinctes, et seule la seconde se configure explicitement.

La conséquence, qui est contre-intuitive

Si votre exigence de résidence est réelle, elle vous prive des modèles les plus récents chez votre fournisseur principal. Chez Microsoft, c’est documenté : les modèles sortent d’abord sur les déploiements globaux. Chez les autres, comparez la liste des modèles offerts dans la région canadienne à la liste globale avant de conclure.

C’est là que le multi-modèle cesse d’être une optimisation de performance et devient une réponse structurelle : un modèle contraint géographiquement pour les traitements qui touchent des renseignements personnels, un modèle plus récent et moins contraint pour tout le reste. Le critère de répartition n’est pas la qualité du modèle. C’est la sensibilité de la donnée.

Cette architecture a un nom simple : deux voies, une frontière claire entre les deux, et une règle écrite qui dit ce qui passe par où.

Trois critères pour trancher

1. Avez-vous une exigence de résidence, vraiment ? Pas « on préférerait ». Une exigence documentée, qui touche des renseignements personnels identifiables. Rappel utile : la Loi sur le privé n’interdit pas d’envoyer un renseignement personnel hors du Québec, elle exige une ÉFVP avant de le faire (article 17). Un routage d’inférence vers une région américaine entre dans ce cas dès qu’un renseignement personnel figure dans la requête. Si oui, le multi-modèle devient probable, parce qu’un seul fournisseur ne couvrira pas bien les deux besoins. Si non, un modèle suffit presque toujours.

2. Qui maintient le routage ? Nommez la personne. Si vous ne pouvez pas, vous n’avez pas d’architecture multi-modèle, vous avez une dette technique en préparation.

3. Le volume justifie-t-il la complexité ? L’écart de coût entre deux modèles ne devient significatif qu’au-dessus d’un certain volume d’appels. En dessous, la différence de facture ne paie pas les heures de maintenance. Notre méthode de mesure s’applique telle quelle ici : établissez le coût réel avant de changer d’architecture.

Quand c’est prématuré

Pour la majorité des PME que nous voyons, le multi-modèle arrive trop tôt. Les signes : aucun processus n’est encore mesuré, personne ne sait quel volume d’appels est réellement produit, et le choix se justifie par un comparatif lu en ligne plutôt que par un test sur vos propres données.

Le bon ordre reste le même que pour l’outillage d’automatisation : le processus d’abord, la mesure ensuite, l’architecture en dernier. Un modèle bien intégré dans un processus cartographié bat deux modèles branchés sur une intuition.

Ce qu’il faut demander par écrit

Peu importe le fournisseur, trois questions dont la réponse doit être écrite au contrat, pas dans une page marketing : où les requêtes sont-elles traitées, où les données sont-elles conservées au repos, et les contenus servent-ils à entraîner des modèles. Un fournisseur qui répond clairement aux trois vous simplifie l’inventaire. Un fournisseur qui répond de façon vague vient de répondre.

Pour situer vos usages avant de toucher à l’architecture : notre évaluation Loi 25 et IA pose les questions dans l’ordre. Et si la question du routage se pose concrètement chez vous, on la démêle avec vous.