IA pour franchises et entreprises multisites : ce qu'on centralise et ce qu'on laisse en local

Scénario illustratif. Un réseau de douze sites met un agent IA face à ses clients. Six semaines plus tard, il existe douze versions de l'agent : chaque site a retouché les consignes « juste un peu ». L'un accorde les remboursements à 45 jours, un autre annonce les horaires d'été en novembre, un troisième tutoie un client que la marque vouvoie toujours. Personne n'a rien fait d'étrange. La même décision a été prise douze fois, sans que personne ne la prenne vraiment.

La thèse en une ligne : dans un réseau de sites, on ne choisit pas quel agent acheter, on décide ce qu'on configure une fois et ce qu'on adapte par site. Le premier se centralise sans débat ; le second reste local, mais comme une donnée, pas comme une copie de l'agent.

IA pour franchises et entreprises multisites : qu'est-ce qu'on configure une fois, et qu'est-ce qu'on adapte par site ?

On configure une fois tout ce qui définit le comportement de l'agent : règles de décision, limites de ce qu'il peut accorder, ton, permissions, moment où il passe la main à une personne et manière de l'évaluer. On adapte par site ce qui change vraiment d'un endroit à l'autre : catalogue et prix locaux, horaires et jours fériés, l'équipe vers laquelle part chaque cas, la réglementation du lieu et la langue. La question qui ordonne tout le reste est simple : cette différence existe-t-elle pour une vraie raison métier, ou par habitude du site ? Seule la première mérite un paramètre.

Qu'est-ce qu'on centralise toujours ?

• Les règles de décision. Délais de retour, remises maximales, ce qu'on peut promettre ou non. Si chaque site a sa version, le client qui change de site change de marque. La façon de les écrire est détaillée dans les instructions d'un agent IA.
• Les permissions. Les systèmes que l'agent touche et jusqu'où. Une permission accordée sur un site par commodité devient une permission accordée partout dès que quelqu'un copie la configuration. Les critères sont dans les permissions d'un agent IA.
• Le ton et la voix. C'est ce que le client reconnaît comme la marque. On le définit une fois, on le teste une fois.
• L'évaluation et la traçabilité. La même batterie de tests pour tous les sites et un seul endroit où voir ce que l'agent a fait. Sans cela, impossible de comparer un site à un autre.
• L'escalade. La règle qui dit quand l'agent s'arrête et passe la main est centrale ; à qui il la passe sur chaque site est une donnée locale.

Qu'est-ce qui s'adapte par site (et comment, sans copier l'agent) ?

Le local entre comme un paramètre que l'agent consulte, pas comme une version différente de l'agent. La nuance paraît mince et change tout : un paramètre se met à jour à un endroit et le changement se voit ; une copie, il faut courir après.

• Catalogue, prix et disponibilité, qui vivent déjà dans le système de chaque site ou dans le système central. L'agent les lit, il ne les retient pas.
• Horaires, jours fériés et fermetures temporaires, avec une date de validité pour que les horaires d'été ne survivent pas à l'été.
• Personnes et canaux d'escalade : qui reçoit le cas sur chaque site, et par quel canal.
• Réglementation et conditions locales. Ce qu'on peut dire ou promettre change selon le lieu. Dans un réseau qui traverse plusieurs pays, c'est un paramètre par marché, jamais un chiffre ou une règle recopiés d'un pays à l'autre.
• Langue et forme d'adresse, quand les clients d'un site attendent autre chose.

Un agent pour tous les sites ou un par site ?

Le point de départ raisonnable est un agent avec une configuration par site. Un agent par site ne se justifie que lorsque les différences cessent d'être des paramètres. Les arbitrages, sans maquillage :

• Un agent avec configuration par site. Un changement de politique atteint tous les sites en même temps et s'évalue une seule fois. En contrepartie, une erreur centrale se propage à tout le réseau dans la même minute, et la configuration par site exige de la discipline : qui peut y toucher, qui la relit.
• Un agent par site. Chaque site s'adapte comme il veut et une panne reste chez lui. En contrepartie, douze versions à maintenir, douze évaluations, douze endroits où une règle peut être périmée, et un an plus tard on ne sait plus ce que fait chacune.
• Un hybride par pays ou par format. Un agent par marché ou par type de site (magasin, clinique, atelier), avec la partie commune partagée. C'est le compromis quand la réglementation, la langue ou les systèmes changent réellement d'un groupe à l'autre.

Maintenir cet ensemble en vie est une fonction continue, pas un projet qu'on livre : qui met à jour, qui relit, qui répond quand un site dérive. C'est l'objet de passer de 5 à 100 agents.

Comment déployer sans que les sites le vivent comme une imposition ?

1. Commencez par deux sites différents, pas par le plus confortable. Un grand et un petit, ou un qui vend et un qui rend un service. Si la conception tient pour deux cas différents, elle tient pour les autres avec des ajustements.
2. Donnez à chaque site un responsable au pouvoir borné. Il peut changer les paramètres locaux (horaires, équipe, promotions) ; il ne peut pas changer les règles centrales. S'il faut changer une règle, il la propose et on la tranche une fois pour tous.
3. Rendez visible ce qui est central et ce qui est local. Une page avec les deux listes. La plupart des conflits avec les sites viennent de ce que personne ne sait où s'arrête sa marge.
4. Surveillez la dérive, pas chaque réponse. Un échantillon régulier par site suffit pour voir qui s'écarte des règles et pourquoi.

Dans une franchise, il existe en plus une couche qui n'est pas technique : ce que le contrat permet d'imposer au franchisé et ce qu'il ne permet pas, et qui répond devant le client si l'agent se trompe. Cela se règle par le contrat et un conseil juridique, pas par un prompt. Ce que vous pouvez faire côté conception, c'est établir clairement qui possède chaque règle, comme le propose gouverner les agents IA dans l'entreprise.

Comment mesure-t-on site par site ?

Avec la même batterie de tests sur tous les sites et des résultats séparés par site. La lecture est directe : si un défaut n'apparaît que sur un site, c'est un problème de configuration locale ; s'il apparaît sur plusieurs, c'est une règle centrale à corriger. Sans cette séparation, une erreur centrale ressemble à une anecdote locale et une erreur locale à une défaillance de l'agent. Le cadre général pour répartir qui contrôle quoi se trouve dans gouvernance et contrôle de l'automatisation par IA.

Quand NE PAS centraliser ?

Quand les sites sont, dans les faits, des entreprises différentes : une acquisition récente avec d'autres systèmes, une autre marque, un autre public, ou une réglementation qui change ce que l'agent peut dire. Imposer un agent commun dans ce cas produit un agent qui ne sert personne. Cela ne vaut pas non plus la peine avec deux ou trois sites identiques : configurez bien un agent et copiez le résultat à la main tant que c'est gérable. La centralisation se paie en discipline, et cette discipline ne rapporte que lorsque le nombre de sites rend l'alternative intenable.

La phrase à retenir : ne demandez pas de combien d'agents vous avez besoin, demandez combien de versions de vos règles vous êtes prêt à maintenir. Si la réponse est « une », tout le reste est un paramètre.

Remarque : cet article n'utilise aucun chiffre de tiers. Les conditions contractuelles d'une franchise et la réglementation locale dépendent de chaque cas et de chaque pays ; demandez un conseil juridique avant de décider ce qu'il faut imposer à chaque site.