Intégrer un assistant IA dans une application SaaS

Pour mettre un assistant IA dans votre application en ligne, trois voies existent : coller le widget fourni par la plateforme, construire votre propre fenêtre de conversation qui appelle la plateforme par son API (interface de programmation), ou, plus rarement, afficher l'assistant dans un cadre intégré. Dans les trois cas, deux sujets reviennent : transmettre de façon sûre l'identité de l'utilisateur connecté, et autoriser l'assistant dans la politique de sécurité de votre application. Cette page donne les principes ; les détails dépendent toujours de la documentation de l'outil choisi.

Les trois voies

Un premier lancement par le widget, puis un passage à l'API pour les écrans où l'assistant doit être plus présent, est un chemin fréquent. Selon sa documentation d'API, relevée le 15/11/2026, ALMA, la plateforme d'assistants éditée par IArche, propose les deux : un widget à coller sous forme de balise <script>, avec un exemple pour React, et une API REST avec des webhooks sortants signés, c'est-à-dire des notifications que la plateforme envoie à votre serveur quand un événement se produit.

L'identité de l'utilisateur connecté

Dans votre logiciel, l'utilisateur est connecté. L'assistant peut en tirer parti : ne pas redemander son nom, rattacher la conversation à son compte, filtrer la documentation selon son forfait. Mais transmettre cette identité ne s'improvise pas.

Le principe : un jeton signé par votre serveur. Votre serveur, qui sait qui est connecté, fabrique un jeton qui décrit l'utilisateur et le signe avec une clé secrète. Le navigateur le transmet à l'outil, qui vérifie la signature. Le format le plus courant est le JWT (JSON Web Token), défini par la RFC 7519 de mai 2015 comme « a compact, URL-safe means of representing claims to be transferred between two parties ». Il porte notamment un identifiant du sujet (sub), une date d'émission (iat) et une date d'expiration (exp).

Deux exemples documentés, relevés le 15/11/2026 :

• Zendesk authentifie les utilisateurs de sa messagerie par des JWT signés. L'administrateur crée une clé de signature et transmet son secret au développeur de façon confidentielle ; un service côté serveur crée les jetons. Le jeton doit contenir un external_id, identifiant unique de 255 caractères au plus qui ne doit jamais changer. Le but affiché : rattacher toutes les conversations d'un utilisateur au bon compte, d'un appareil à l'autre, et protéger les informations sensibles.
• Intercom a longtemps utilisé un code de vérification (HMAC) calculé sur le serveur pour chaque utilisateur. Sa page d'aide explique pourquoi : sans vérification, un utilisateur pourrait se faire passer pour un autre et voir ses conversations. Elle insiste : la clé ne doit jamais se trouver dans le code exécuté par le navigateur ni dans le dépôt de code. Cette méthode y est présentée comme dépréciée au profit des JWT.

Et l'authentification unique (SSO) ? Si votre logiciel connecte déjà ses utilisateurs par un fournisseur d'identité, avec OpenID Connect par exemple (protocole d'authentification « based on the OAuth 2.0 framework », selon openid.net), cela règle la connexion à votre logiciel. Cela ne transmet pas automatiquement l'identité à l'assistant : c'est votre serveur qui, une fois l'utilisateur connecté, émet le jeton destiné à l'outil.

Le site sur les chatbots de la même famille détaille, pour un site client, les précautions de l'identification d'un client connecté : ne transmettre que le nécessaire, tester la déconnexion sur un poste partagé.

La politique de sécurité du contenu

Beaucoup d'applications en ligne envoient un en-tête Content-Security-Policy. Selon MDN, la documentation web de Mozilla, c'est « une série d'instructions d'un site web à un navigateur » qui restreint ce que le code de la page peut faire. La directive script-src « définit les sources autorisées pour JavaScript » : si le domaine de la plateforme n'y figure pas, le widget ne se charge pas.

Avant l'intégration, demandez au fournisseur la liste exacte des domaines à autoriser (scripts, connexions, images, cadres), et ajoutez-les de façon ciblée. MDN note que les listes d'autorisations par domaine peuvent devenir très longues et difficiles à maintenir : préférez un fournisseur qui en demande peu.

La liste de contrôle de l'intégration

• Le secret de signature n'apparaît que côté serveur
• Le jeton expire, et se renouvelle sans couper la conversation
• Un utilisateur ne voit jamais la conversation d'un autre, même sur le même poste
• L'assistant fonctionne aussi pour un utilisateur sans droits d'administration
• La politique de sécurité autorise uniquement les domaines nécessaires
• Les webhooks reçus sont vérifiés (signature) avant d'être traités
• L'assistant s'affiche correctement sur les écrans étroits de votre application
• Une panne de la plateforme n'empêche pas d'utiliser le logiciel

Si l'assistant doit, en plus, lire des données du compte ou agir dans le logiciel, lisez d'abord assistant ou copilote : les droits qu'on lui donne changent la nature du projet.