Saas vs on-premise pour l'IA conversationnelle

Une direction reçoit une demande simple : automatiser les réponses du service client. Le débat se réduit vite à deux cases, SaaS ou on-premise. Ce cadrage est faux. Un assistant qui répond sur un catalogue produit n'engage pas le même risque qu'un agent qui interprète un contrat d'assurance ou accompagne une entrée en relation bancaire. L'hébergement suit la donnée.

Ce guide déroule la décision dans l'ordre où elle se prend. D'abord les trois modes d'hébergement et les huit critères de comparaison. Ensuite ce que le droit impose, les cas par secteur et les questions à poser à un fournisseur. Enfin ce qui casse en production, et la feuille de route.

Trois modes d'hébergement, et lequel pour quel flux

Vous ne choisissez pas un hébergement pour votre agent IA en général. Vous choisissez un niveau de protection pour une donnée, un parcours et une responsabilité métier. Une question de catalogue vit en SaaS, un dossier contractuel demande un cloud qualifié ou vos propres serveurs. Rien ne vous oblige à retenir un seul mode pour toute l'entreprise.

Les trois modes se distinguent par qui exploite et qui répond. En SaaS, le prestataire héberge et exploite le service pour l'ensemble de ses clients. En cloud qualifié, un hébergeur certifié opère un environnement dédié à votre organisation. En on-premise, le système tourne chez vous, sur vos machines, avec vos équipes.

• SaaS standard, pour les parcours peu sensibles. L'infrastructure, les mises à jour et une partie de la sécurité restent chez le prestataire.
• Cloud qualifié SecNumCloud, quand vous voulez les propriétés du cloud sans lâcher la main sur les accès et la juridiction. SecNumCloud est le label de sécurité délivré aux hébergeurs par l'ANSSI, l'agence nationale de la sécurité des systèmes d'information.
• Hébergement chez vous, quand la charge doit rester isolée. Les dépendances externes tombent, l'exploitation devient votre travail.

Pour leurs systèmes sensibles, l'ANSSI oriente les organismes concernés vers des offres cloud privées ou communautaires qualifiées SecNumCloud.¹ Vérifiez que la qualification couvre le service que vous achetez, et pas seulement le catalogue du fournisseur.

Les architectures qui tiennent mélangent souvent les trois. Une question de catalogue part en SaaS. Un dossier contractuel reste dans un environnement qualifié. Un corpus très sensible ne sort jamais de chez vous.

Pour situer les options, vous pouvez comparer les solutions d'IA conversationnelle de Webotit avec les offres SaaS, qualifiées et internes de votre marché.

Huit critères à comparer avant de trancher

Une comparaison sérieuse ne confond pas vitesse d'achat et coût complet, ni disponibilité technique et maîtrise juridique. Huit critères suffisent à cadrer la décision : le coût complet, la sécurité, la conformité, la montée en charge, l'intégration, l'exploitation, les engagements de service et la souveraineté.

Le coût complet ne se limite pas à l'abonnement

Le coût complet, c'est l'abonnement plus tout ce qui le rend utile. La connexion au CRM, la préparation des documents, la supervision des réponses, la gestion des incidents et la reprise des données. Le SaaS réduit la dépense de démarrage. L'hébergement interne la déplace vers l'infrastructure et les compétences.

Prenons un centre qui traite 30 000 conversations par mois, dont un tiers de simples demandes de suivi de dossier. Le chiffre utile n'est pas le prix de la licence. C'est le coût par conversation réellement close. Additionnez l'abonnement, l'intégration amortie sur la durée du contrat, la supervision humaine et l'hébergement. Divisez ensuite par le nombre de demandes closes sans intervention humaine.

Faites ce calcul pour les trois modes, sur la durée d'engagement que vous envisagez. Le classement peut s'inverser entre la première et la troisième année : c'est le coût complet sur la durée qui compte.

Distinguez ensuite une charge stable d'une charge irrégulière. Une activité conversationnelle prévisible et intensive rend une capacité dédiée intéressante. Une activité saisonnière, ou encore en expérimentation, profite de la capacité du cloud à s'ajuster automatiquement au volume.

Ajoutez enfin la ligne que personne ne chiffre au départ : la sortie. Reprendre vos historiques, réindexer vos documents ailleurs et reconstruire vos connexions coûte du temps. Faites chiffrer cette ligne avant de signer, pas après.

Sécurité, performance et engagement de service se lisent ensemble

Une garantie de disponibilité élevée ne répond pas à une exigence de souveraineté. Un engagement à 99,95 %, par exemple, autorise encore un peu plus de quatre heures d'interruption par an. Le même engagement n'a pas la même portée juridique selon le prestataire. Un grand fournisseur mondial, un hébergeur qualifié et votre propre équipe n'offrent pas les mêmes recours.

Mesurez la performance sur le parcours entier. Le temps d'accès aux documents, la réponse du CRM et le délai de transfert vers un conseiller pèsent autant que la vitesse du modèle. Un modèle rapide branché sur un CRM lent donne un agent lent.

Les équipes qui automatisent des tâches administratives peuvent regarder les agents IA de back-office, en vérifiant surtout l'intégration, la supervision et la réversibilité.

RGPD et SecNumCloud : ce que le droit vous impose

Le RGPD ne se résume pas au choix d'un hébergeur européen. Avant de comparer des offres, écrivez la finalité du traitement, sa base légale et les catégories de données. Ajoutez la liste des personnes qui accèdent aux conversations et la durée de conservation. Ces cinq lignes orientent l'hébergement mieux que n'importe quelle brochure.

Les articles du RGPD qui décident de votre hébergement

Deux articles cadrent la décision.³ L'article 5 pose les principes : une finalité définie, des données limitées au nécessaire, une conservation bornée dans le temps, une sécurité adaptée au risque. L'article 6 liste les bases légales possibles, notamment le contrat, le consentement ou l'intérêt légitime selon le parcours.

Le reste du texte se lit comme une liste de contrôles. Vous devez informer les personnes de ce que vous faites de leurs données conversationnelles (article 13). Vous devez encadrer par un contrat écrit (article 28) chaque sous-traitant qui héberge ou traite ces conversations, y compris l'éditeur du modèle.

L'article 22 encadre aussi les décisions entièrement automatisées qui produisent un effet juridique ou significatif pour une personne. Celle-ci peut demander une intervention humaine. Un refus de dossier ne se signe donc pas tout seul. L'IA prépare, l'humain valide.

Une analyse d'impact précède le pilote quand le traitement présente un risque élevé pour les personnes. Pour un agent qui lit des conversations clients, elle couvre le modèle, les données injectées, les journaux, les transferts, l'effacement et les scénarios d'erreur. Votre délégué à la protection des données doit pouvoir dire ce que le système conserve et ce qu'il transmet.

Ce que couvre, et ne couvre pas, la qualification SecNumCloud

Le référentiel SecNumCloud 3.2 couvre près de 1 200 exigences et vise notamment la protection contre les lois extraterritoriales.² Vérifiez que la qualification couvre le service que vous achetez : elle est délivrée à une offre précise, pas à un fournisseur. Demandez le périmètre exact et la date de la qualification, par écrit.

Ne transformez pas pour autant chaque donnée en charge souveraine. Une FAQ publique ou un catalogue produit vivent très bien dans un environnement moins contraint. Un corpus de contrats, une conversation médicale ou un dossier stratégique justifient un cloud qualifié, voire un hébergement chez vous.

Quatre clauses à obtenir par écrit

Le droit devient utile quand il descend dans le contrat. Quatre clauses transforment vos obligations en engagements vérifiables. Obtenez-les avant la signature, quand vous avez encore un moyen de pression.

• Journalisation : quelles traces récupérez-vous pour expliquer une réponse ou instruire un incident, et pendant combien de temps ?
• Effacement : quelle procédure s'applique aux conversations, aux index documentaires et aux sauvegardes ?
• Portabilité : quels formats et quelles connexions vous rendent vos données, vos documents et votre configuration ?
• Gouvernance : qui décide entre l'éditeur, l'hébergeur, la direction informatique et le métier, et en combien de temps ?

Banque, e-commerce, santé : la donnée décide, pas le secteur

Le mode pertinent dépend de la donnée réellement traitée, pas du secteur affiché sur la brochure. Une banque fait cohabiter plusieurs architectures dans un même parcours client, à condition de séparer les flux et les responsabilités. Le tableau ci-dessous donne un point de départ, à confronter à votre cartographie des données.

Un agent qui explique une clause contractuelle accède à des données personnelles et produit une réponse engageante. Un agent d'entrée en relation ajoute une contrainte de traçabilité. Vous devez savoir quelles données ont servi, quelle règle a été appliquée, et à quel moment un conseiller a repris la main.

En e-commerce, la faible sensibilité du catalogue rassure à tort. Les historiques d'achat, les coordonnées client et les informations de paiement changent la criticité du flux dès que l'agent y accède. Séparez l'information publique du dossier client avant d'élargir le périmètre.

Un agent de prise de rendez-vous ne présente pas le même risque qu'un agent qui reçoit des symptômes. Un assistant étudiant traite une demande administrative simple, ou un accompagnement individuel sensible. L'hébergement suit cette différence, avec une exigence renforcée dès que des données de santé entrent dans le parcours.

Pour les appels entrants, comparez le callbot de relation client sur trois points. Le périmètre des données vocales, la durée de conservation des transcriptions, et le mécanisme de transfert vers un conseiller.

Le volume pèse sur le coût et sur la capacité, jamais seul sur le mode. Une petite volumétrie sur une donnée réglementée justifie une architecture plus contrôlée qu'un très grand volume de questions publiques. Croisez donc la criticité de la donnée et le volume attendu.

Les questions à poser à un fournisseur, et les bonnes réponses

Un appel d'offres se juge moins sur la démonstration que sur les réponses écrites. Voici les questions que je poserais, et ce qu'une bonne réponse contient. Une réponse orale, ou renvoyée à la mise en œuvre, vous apprend déjà quelque chose sur la maturité de votre interlocuteur.

• Où sont hébergées les données, et sous quelle juridiction ? Une bonne réponse nomme le pays, l'entité juridique et le sous-traitant d'infrastructure.
• Le service que j'achète est-il qualifié, ou seulement une partie de votre offre ? Une bonne réponse joint le périmètre et la date de la qualification.
• Quels documents partent vers le modèle, et à quel moment ? Une bonne réponse décrit le flux et dit si vos contenus servent à entraîner un modèle.
• Que conservez-vous, et pendant combien de temps ? Une bonne réponse distingue les conversations, les journaux techniques et les sauvegardes.
• Comment supprimez-vous une conversation à la demande d'un client ? Une bonne réponse décrit une procédure, un délai et une preuve d'exécution.
• Que se passe-t-il quand l'agent ne sait pas répondre ? Une bonne réponse montre la règle de transfert vers un conseiller, pas une formule d'excuse.
• Puis-je changer de modèle sans refaire l'intégration ? Une bonne réponse sépare le moteur, la base documentaire et les connexions.
• Comment sort-on du contrat ? Une bonne réponse donne les formats d'export, le délai, le prix, et un test de sortie réalisable avant la bascule.
• Qui répond en cas d'incident, et sous quel délai ? Une bonne réponse nomme un interlocuteur, des horaires et une procédure d'escalade.

Deux réponses doivent vous arrêter net. Un fournisseur qui refuse d'écrire le périmètre de sa qualification vous vend un label, pas un service. Un fournisseur qui promet un taux de résolution avant d'avoir vu vos données vous vend une démonstration.

Faites répondre par écrit, puis relisez les réponses avec votre délégué à la protection des données et votre responsable achats. Les écarts entre le discours commercial et le contrat apparaissent à ce moment-là.

Les échecs d'hébergement ont presque toujours la même cause

Les projets d'agent conversationnel échouent rarement sur le modèle. Ils échouent sur une base documentaire périmée, sur l'absence de règle de transfert, et sur des journaux qui ne permettent pas d'expliquer une réponse. Le mode d'hébergement ne corrige aucun de ces trois défauts. Il change seulement le coût de la réparation.

• La base documentaire vieillit. Les réponses justes au lancement deviennent fausses au premier changement de tarif ou de procédure.
• Le transfert vers un conseiller n'a pas de règle. L'agent insiste au lieu de passer la main, et le client répète trois fois sa demande.
• Les journaux existent mais ne relient pas la réponse aux documents utilisés. Une réclamation devient impossible à instruire.
• Le périmètre s'élargit sans repasser par la cartographie des données. Un flux sensible emprunte le chemin prévu pour une question de catalogue.
• La supervision s'arrête après le pilote. Plus personne ne relit les réponses, et les erreurs cessent de remonter.
• Les accès d'administration ne sont pas tracés. Vous ne savez pas qui a changé une instruction, ni quand.
• La réversibilité n'a jamais été testée. La clause existe, l'export n'a jamais tourné.

Les erreurs de début de projet

Choisir l'hébergement avant d'avoir classé les données. La classification prend deux ateliers et évite des mois de rattrapage. Elle donne aussi la seule chose qui rende la comparaison possible : la liste des flux à protéger.

Confondre chiffrement et souveraineté. Le chiffrement protège la donnée, il ne change pas le droit applicable à l'entreprise qui l'héberge. Les deux sujets se traitent séparément.

• Prendre la qualification d'un fournisseur pour celle du service acheté.

• Lire un engagement de disponibilité comme une garantie juridique.

• Confondre réponse fournie et demande close, puis se féliciter d'un taux de résolution qui n'existe pas.

• Négocier le prix de la réversibilité après la signature, quand vous n'avez plus le choix du fournisseur.

Du pilote à la bascule : mesurer, puis décider

Un pilote utile ne démontre pas que l'agent sait répondre. Il vérifie qu'il répond au bon niveau de fiabilité, qu'il sait refuser ou transférer une demande, et que vous pouvez auditer son comportement. Gardez un périmètre étroit, cinq à dix cas d'usage au plus, et instrumentez dès le premier jour.

• Résolution automatisée, en distinguant la réponse fournie de la demande réellement close.
• Transfert vers un conseiller, avec la cause et les informations transmises.
• Satisfaction après conversation, reliée au type de parcours.
• Durée de traitement, de la première sollicitation jusqu'à la résolution.
• Coût par conversation résolue, usage du modèle, intégrations et supervision compris.
• Disponibilité observée, comparée à l'engagement contractuel et aux incidents vécus.

La supervision humaine commence avant l'industrialisation. Des relecteurs, souvent des conseillers expérimentés, relisent les réponses, classent les erreurs et repèrent les passages mal sourcés. Le registre conserve les instructions données au modèle, les données injectées, les versions de la base documentaire et les réponses produites.

La feuille de route tient en cinq étapes.

1. Cadrage : cartographie des données, objectifs métier et règles de transfert vers un humain.
2. Pilote : périmètre réduit, supervision systématique.
3. Industrialisation : sécurité, supervision, connexions et gouvernance.
4. Bascule vers le mode cible : SaaS, cloud qualifié, hébergement interne ou combinaison des trois.
5. Exploitation confiée à un prestataire ou gardée en interne : revues de performance, audits, mises à jour et tests de sortie.

Une base de connaissance IA pour le service client fait un bon périmètre de test à l'étape du pilote. Le corpus est délimité, les erreurs se voient vite, et la question de l'hébergement se pose sur un volume de documents que vous maîtrisez.

Les délais et le budget se chiffrent avec votre fournisseur, parcours par parcours : je me méfie des fourchettes génériques. La même feuille de route ne coûte pas la même chose selon l'état de vos données et le nombre de connexions à créer.

La décision de passage à l'échelle ne repose pas sur la performance brute. Vérifiez la réversibilité, l'auditabilité, la capacité à purger les données et la possibilité de changer de modèle ou d'hébergeur.

Je ne crois pas au choix unique. La trajectoire la plus solide combine SaaS, cloud qualifié et hébergement interne, avec une segmentation claire et des contrats réversibles. Prévoyez des interfaces qui laissent déplacer un composant sans reconstruire tout le parcours. La bonne architecture n'impose pas un mode : elle empêche une donnée sensible d'emprunter par défaut le chemin de la donnée ordinaire.

Trois actions ne demandent aucun budget, et vous pouvez les lancer cette semaine.

• Listez vos parcours clients, puis classez chaque flux en donnée ordinaire, sensible ou réglementée.
• Demandez par écrit à chaque fournisseur pressenti le périmètre exact de sa qualification et sa procédure d'effacement.
• Faites chiffrer la sortie de contrat, avant la signature.

Si le sujet porte sur la relation client, les agents IA de relation client sont un bon point de départ pour cadrer ce périmètre avec vos équipes.

FAQ sur le choix SaaS ou on-premise

Comment garantir la réversibilité ?

Le contrat doit prévoir la portabilité des modèles, des bases de connaissances, des historiques et des journaux, via des connexions ouvertes entre logiciels. Testez la sortie avant la bascule vers le mode cible. Sans ce test, la réversibilité reste une promesse documentaire.

Comment articuler le modèle et vos documents ?

Le modèle de langage peut rester en SaaS géré pendant que la base documentaire qu'il interroge (le RAG) vit dans un cloud qualifié. Quand le corpus métier est très sensible, l'ensemble part chez vous. Le choix dépend de la donnée transmise au modèle, pas du nom de la technologie.

Peut-on commencer en SaaS puis passer chez soi ?

Oui, à condition de l'avoir prévu au départ. Séparez le moteur, la base documentaire et les connexions métier dès le premier jour. Écrivez la clause de sortie dans le contrat initial, et faites tourner l'export au moins une fois pendant le pilote.

Faut-il un cloud qualifié pour un chatbot de questions publiques ?

Rarement. Un agent qui répond sur un catalogue, des horaires ou des conditions de retour traite de l'information publique. La question change dès qu'il accède au dossier client, à un historique de commandes ou à un moyen de paiement.

Qui décide, la direction informatique ou le métier ?

Les deux, sur des questions différentes. Le métier décide des parcours automatisés et du niveau de service attendu. La direction informatique décide de l'architecture, des accès et de l'hébergement. Le désaccord se tranche sur la classification des données, pas sur les préférences technologiques.

Sources et references

1. [1]ANSSI — Recommandations pour l'hébergement des systèmes d'information sensibles dans le cloud
2. [2]ANSSI — Cloud de confiance et qualification SecNumCloud
3. [3]EUR-Lex, Règlement (UE) 2016/679 du 27 avril 2016 (RGPD), articles 5, 6, 13, 22 et 28