Expertise · Intégrations et automatisations

Que vos systèmes se parlent, sans que quelqu’un doive retaper les mêmes données.

Nous connectons le système de réservations, la boutique, le CRM, les feuilles de calcul et les canaux de messages, afin qu’un agent ou une règle planifiée puisse y lire et y écrire en temps réel. Les clés restent sur le serveur, les outils ont des limites écrites, et chaque intégration est aussi testée sur le cas où l’autre système tombe en panne.

Discuter d'un projet

Déjà construitIntégrations propres, écrites et exécutées, mesurées aujourd’hui dans le code : le connecteur pour le système de réservation Altegio (946 lignes, avec six outils exposés à l’agent), le connecteur CRM amoCRM (2.888 lignes dans la plateforme de messagerie, plus 12 fonctions serveur dans la plateforme vocale), Bitrix24 (903 lignes, plus 4 fonctions), Google Sheets (615 lignes, plus 10 fonctions et un compte de service dédié), le catalogue vivant au-dessus de la boutique (service de plateforme, 318 lignes), les notifications de lead sur Telegram (1.776 lignes), les SMS via Infobip avec des limites anti-abus, les automatisations programmées (1.088 lignes) et le canal de chat d’une plateforme locale d’annonces (2.459 lignes). En exécution, l’agent peut appeler 15 types d’outils internes, en plus des outils via webhook et des outils avec du code propre exécuté en isolation.

Une intégration n’est pas un logo sur une page. C’est la réponse à une question très concrète : ce système peut-il être lu et écrit en temps réel, par qui, avec quels droits, et que se passe-t-il quand il ne répond pas ? C’est pourquoi notre première question pour toute intégration n’est pas « avec quelle API », mais « quelle porte publique a-t-elle ». Parfois, la réponse change complètement le coût du travail : les boutiques sur WooCommerce, par exemple, exposent publiquement une API de boutique qui ne demande aucune clé de consommateur, donc un nouveau client se connecte seulement avec l’adresse de son site — pas avec des credentials qu’il faut générer, envoyer, puis faire tourner.

Dans notre plateforme de messagerie, un outil que l’agent peut appeler pendant la conversation a l’un de trois types : appel vers un webhook, code propre exécuté en isolation, ou un outil interne de la plateforme. Les outils internes sont ceux que nous préférons, parce qu’ils gardent les clés hors de la base de données : aujourd’hui, il y en a quinze, de la lecture d’une page et de l’écriture dans une feuille de calcul, jusqu’à la disponibilité et la création d’une réservation, l’envoi d’un SMS et l’interrogation du catalogue de produits.

La différence entre une intégration qui tient et une qui se casse tient presque toujours à de petits détails, sur le terrain. Le système de réservations ne renvoie rien si vous demandez les créneaux d’un spécialiste pour un service qu’il ne fait pas — le service et le spécialiste voyagent toujours ensemble. Le même système répond par un refus si la requête arrive avec l’en-tête par défaut de la bibliothèque HTTP, donc chaque requête doit s’identifier explicitement. Une boutique peut renvoyer un prix zéro pour les produits avec variantes, et une recherche sur des mots vides renvoie tout le catalogue. Il y a dix détails de ce genre par intégration, et aucun n’est dans la documentation.

Au-dessus des intégrations, il y a les automatisations : des règles qui s’exécutent dans le temps, et non à la demande de quelqu’un. Chez nous, elles sont programmées avec un planificateur dans le processus — reprise des conversations restées sans réponse, premier message à un nouveau contact, mise en pause et redémarrage de l’agent après les heures de travail — chacune avec ses propres compteurs, pour voir combien d’exécutions ont eu lieu, combien de messages sont partis, combien ont été sautés et pourquoi. Une automatisation sans compteur est une automatisation dont vous ne pouvez pas dire si elle fonctionne.

Automatisation transparente — intégrations vérifiables · vidéo en roumain, avec sous-titres et transcription en français

La transcription complète

Entrons directement dans le sujet. Aujourd’hui, nous allons disséquer les réalités techniques et, franchement, souvent ignorées, de l’automatisation par assistants basés sur l’intelligence artificielle. Nous allons nous concentrer sur une approche ultra pragmatique de la plateforme iCat.md développée par Mega Promoting. Nous n’avons pas de promesses marketing aujourd’hui et, certainement, pas de concepts vagues. Nous parlons d’une plateforme directement en production, avec des fonctionnalités expliquées directement à partir de l’architecture de la base de données. Alors, voyons à quoi ressemble, en réalité, une automatisation totalement transparente. L’agenda de cette analyse est simple et direct. Nous passons par le problème du temps, la mécanique de la technologie, un cas réel, les limites claires du système, la gestion des données et les étapes suivantes.

Nous commençons par la première section, le problème du temps. Vous connaissez tous cette question extrêmement frustrante ? Pourquoi toute une équipe de support perd-elle de longues heures, jour après jour, à écrire à la main des réponses aux cinq mêmes questions ? L’information existe déjà sur le site de l’entreprise, mais malgré cela, les clients continuent de demander les détails de manière répétée. Et c’est exactement là l’essence de notre problème. Sans solution technique appropriée, toutes ces demandes répétitives encombrent simplement la messagerie directe, peu importe qu’il s’agisse d’Instagram ou de Messenger. Par conséquent, les réponses arrivent avec beaucoup de retard pour les clients qui ont vraiment un problème complexe, les demandes se perdent dans la mer des messages, et tout le processus de support devient pratiquement une boîte noire que vous ne pouvez ni vérifier ni mesurer.

Deuxième partie. Comment la technologie fonctionne-t-elle réellement sous le capot ? Voilà l’affaire. La configuration de la plateforme repose sur quatre étapes très logiques. D’abord, nous connectons les canaux de communication en utilisant du code propre. Ensuite, toute la base de connaissances est indexée. Vient ensuite la liaison des outils qui peuvent exécuter des actions dans vos systèmes existants. Et enfin, et ce détail est vital, on configure un parcours clair enregistré directement dans la base de données, par lequel le bot transmet la discussion à un opérateur humain. Tout est un système visible et parfaitement configurable. Maintenant, un aspect absolument fascinant. Nous ne parlons pas à partir de rien ici. Ce sont des paramètres extraits directement du schéma de la base de données.

Quand l’assistant a besoin d’une réponse, il utilise ce qu’on appelle une recherche hybride. Par défaut, l’algorithme extrait 5 fragments de texte, applique un seuil strict de similitude de 0-70 et accorde une importance de 30% à la correspondance exacte des mots. Tout est traité par le modèle Text Embedding 3 Small. En pratique, le système transforme les mots en concepts mathématiques pour capter le contexte exact. Les réponses ne sont pas des devinettes, mais des mathématiques pures. Retenez ce nombre. 15. C’est une limite technique absolue dans le système. Elle représente le temps maximal, en secondes, alloué pour exécuter n’importe quel outil ou recherche. Si une intégration externe prend plus de temps que cela, disons qu’elle a besoin de 40 secondes, nous ne pouvons pas la laisser dans le flux live de la conversation.

Elle doit être traitée de manière asynchrone, sinon le rythme naturel du dialogue se briserait complètement. Et il y a autre chose. Les gens écrivent sur le chat par rafales, n’est-ce pas ? 2, 3, 4 messages courts envoyés l’un après l’autre. Pour ne pas rendre le système fou, il existe un tampon de concaténation de 15 secondes. Tout ce qui entre dans cette fenêtre est fusionné et devient une seule demande claire. De plus, sur des plateformes comme Meta, où l’on tombe parfois sur des messages dupliqués envoyés par erreur, le système applique un filtre de mémoire de 120 secondes sur l’ID du message. Ainsi, le client reçoit une seule réponse cohérente, et non 3 fausses alertes. Troisième section.

Voyons un cas réel. Nous avons ce scénario classique d’e-commerce. Nous avons une boutique en ligne, avec un catalogue impeccable sur le site, mais qui reçoit une avalanche de messages privés sur Instagram et Messenger ? Est-ce encore en stock ? Quel est le prix ? Ici, l’intégration a été faite avec élégance, en connectant l’assistant directement à l’interface publique Store API de WooCommerce. Sans complications de sécurité, le catalogue vivant de la boutique a simplement été mis entre les mains de l’assistant. Mais c’est là qu’intervient la réalité technique de chaque plateforme, même sous l’ombrelle de la même entreprise, comme Meta. Sur Messenger, l’assistant peut vous montrer de superbes carrousels de produits. Sur Instagram, le bot ne vous répondra qu’avec du texte et, au maximum, une simple image.

Pourquoi ? Tout simplement parce que Meta ne prend pas en charge ces modèles génériques sur Instagram. L’assistant doit jouer exactement selon les règles du canal où il se trouve. Ici se trouve le point critique. Que se passe-t-il lorsque le bot est dépassé par la situation ? Eh bien, dans la base de données, la conversation a des états explicites. Quand une question sort de la zone de confort du catalogue, le fil de discussion passe immédiatement de l’état bot à l’état humain. Et la partie géniale, c’est que le système chronomètre le temps de réponse de l’opérateur humain, en marquant tout clairement, statut OK, avertissement ou délai dépassé. Tout le contexte est transmis à l’humain, sans rien perdre en route.

Section A4 Limites du système Parce que la transparence signifie savoir ce qu’il ne peut pas faire. Il y a quelques limites fermes que nous devons accepter. Vous ne pouvez pas envoyer de messages proactifs sur WhatsApp s’il s’est écoulé plus de 24 heures depuis le message du client. Meta renverra une erreur, plus précisément l’erreur 131047, et l’action échouera. Le système ne fait pas de fichiers RPDF, il ne lit pas les pièces jointes. Pour les langues étrangères, les traductions ne fonctionnent que dans un seul sens. Le client reçoit la réponse traduite, mais l’opérateur voit l’original. Et, bien que l’intégration avec 999.md fonctionne, elle n’est pas officielle et repose sur les cookies du navigateur. Si la plateforme modifie ses mécanismes, la connexion tombe et nécessite des réparations.

Et retenez bien ceci. L’assistant est le miroir de vos données. Un prix erroné sur le site deviendra à coup sûr un prix erroné dans la conversation. Il agit comme un lecteur, pas comme un gestionnaire de boutique. Il ne corrigera pas de sa propre initiative les erreurs humaines dans les catalogues. L’infrastructure technique ici n’est pas un jeu. Tout est hébergé sur un serveur privé Microsoft Azure. Nous parlons d’une base de données MySQL extrêmement structurée, avec plus de 80 tables clairement modélisées pour séparer les canaux et pour l’audit. Les clés d’accès pour WhatsApp, qui sont super sensibles, utilisent le chiffrement fernet. En plus de cela, au niveau du web, les domaines du widget de chat sont ajoutés manuellement à une liste blanche.

Personne ne se connecte sans autorisation explicite. Il faut toutefois aborder une réalité évidente. Les gens vont écrire toutes sortes de données personnelles dans ces fenêtres de chat, numéros de téléphone, adresses. Techniquement, on ne peut pas bloquer un champ de texte libre. La solution est donc administrative. Lorsque vous mettez en place un tel système, vous avez besoin, dès la seconde 1, de politiques de rétention claires qui indiquent exactement qui a le droit de voir ces données et pendant combien de temps elles sont stockées. Et nous sommes arrivés au point 6. Les étapes suivantes. La philosophie centrale de tout le système peut être résumée par cette citation. Un assistant ultime n’est pas celui qui compose des poèmes ou écrit joliment, mais celui qui est connecté à de vraies informations et, très important, sait exactement où il doit s’arrêter.

Une automatisation efficace dans le business signifie la bonne prise en charge des données et l’assurance avec laquelle vous cedez le contrôle à un opérateur humain au moment opportun. Par conséquent, l’étape suivante n’est pas d’acheter un logiciel, mais d’analyser attentivement vos processus actuels. Évaluez quels flux de travail méritent vraiment d’être construits et automatisés, comment ils peuvent être connectés en toute sécurité et, surtout, établissez comment vous allez mesurer les résultats avec des données réelles, et non avec des illusions marketing. Et je vous laisse avec cette question de réflexion. Parmi tous les processus de communication dans une entreprise, lesquels nécessitent vraiment l’empathie et le tact d’un humain et lesquels sont, en fait, seulement des tâches répétitives qui attendent simplement d’être reliées avec précision à la bonne base de données ? Tout plan d’automatisation devrait partir de cette question. Merci d’avoir été avec nous dans cette analyse !

Ce que cela comprend

Le travail, par composantes

Nous vérifions d’abord quelle porte publique le système a

Pour les boutiques WooCommerce, nous utilisons l’API publique de la boutique, qui ne demande pas de clé de consommateur : le client se connecte uniquement avec l’adresse du site. C’est un choix qui a des conséquences réelles, pas seulement esthétiques — nous l’avons remplacé par des outils écrits à la main qui gardaient des clés de boutique en clair dans la base de données. Quand le système n’a pas de porte publique, nous passons à l’authentification, mais alors la clé devient un élément à gérer, et non quelque chose que l’on oublie dans une ligne de base de données.

Les clés restent sur le serveur, pas dans l’outil ni dans la page

L’outil SMS est interne à la plateforme justement parce que l’environnement dans lequel s’exécute le code propre d’un outil n’a pas accès aux variables d’environnement — si l’envoi se faisait depuis le code de l’outil, la clé devrait être écrite dans la base de données, et cette clé peut envoyer des messages aux frais de tous. C’est pareil pour le système de réservations : le jeton partenaire est unique, conservé dans l’environnement du serveur, tandis que le client ne renseigne que l’identifiant de sa propre entreprise.

L’agent appelle l’outil pendant la conversation, avec paramètres et délai

Chaque outil a une description écrite pour le modèle, des paramètres typés avec ce qui est obligatoire ou non, et son propre délai d’exécution — de 15 secondes pour une liste de services jusqu’à 30 pour une recherche de disponibilité. Le délai par outil n’est pas un détail : sans lui, une intégration lente bloque la conversation, et la personne de l’autre côté entend le silence.

De vraies réservations dans le système du salon ou de la clinique

Six outils au-dessus d’Altegio : la liste des services avec les vrais prix, les spécialistes, la disponibilité complète, la création de réservation, l’annulation et la modification. La disponibilité ne renvoie pas seulement « libre/occupé » : elle renvoie quels spécialistes réalisent le service demandé et les premiers créneaux libres pour chacun, classés du plus proche au plus lointain, justement pour que l’agent propose une alternative concrète au lieu de dire « non disponible ».

Le catalogue du magasin, lu en direct

Le prix et la disponibilité sont lus dans la boutique au moment de la question, et non depuis une copie obsolète. Le catalogue est chargé par pages, jusqu’à 30 pages de 100 produits chacune, conservé dans un cache de dix minutes par site et normalisé dans une seule forme, lue sans modification par tous les consommateurs — y compris le carrousel de produits dans la messagerie, qui a besoin d’un prix numérique, et le widget de la page, qui a besoin du titre.

CRM, feuilles de calcul et canaux de messages

amoCRM et Bitrix24 avec OAuth complet, actualisation de jeton et vérification d’état. Google Sheets via un compte de service dédié, séparé du reste des identifiants, avec écriture déclenchée par l’agent. Telegram pour les notifications de leads. SMS via Infobip. Plus le canal de chat d’une plateforme locale de petites annonces, connecté avec son propre jeton d’actualisation — le genre d’intégration qui n’existe dans aucun catalogue international et qui compte énormément localement.

Des automatisations qui s’exécutent dans le temps, avec compteurs

Reprise des conversations restées sans réponse, premier message à un nouveau contact, mise en pause et redémarrage de l’agent après les heures de travail. Chaque exécution incrémente des compteurs visibles : combien d’exécutions, combien de messages envoyés, combien sautés parce que l’agent était arrêté, combien parce qu’il n’avait pas de configuration, combien d’erreurs. Sans eux, le seul moyen de savoir qu’une automatisation est morte est la plainte d’un client.

Des limites anti-abus, parce que la décision est prise par un modèle

Un outil appelé par un modèle linguistique a besoin de limites que le modèle ne peut pas franchir. Pour les SMS : en mode « vers l’entreprise », le destinataire vient de la configuration, jamais du modèle ; en mode « vers le client », le numéro est normalisé et validé. Au-dessus de cela, un plafond quotidien par agent, une pause d’une minute vers le même numéro et une limite de longueur du message. Ce sont des barrières écrites dans le code, pas des instructions dans le prompt — un prompt peut être contourné, une barrière non.

Des filtres à la sortie, pour les données qui n’ont pas le droit de sortir

Lorsqu’une intégration renvoie plus que ce que le client devrait savoir, nous filtrons à la sortie, nous n’espérons pas que l’agent s’abstiendra. Un exemple réel : pour un client du transport, la politique interdit à l’agent de dicter le numéro de téléphone du chauffeur, mais l’API renvoyait ces numéros dans la réponse. Nous avons écrit un filtre qui parcourt récursivement le résultat de l’outil et supprime les champs de contact du chauffeur, tout en conservant les numéros du dispatch. Le filtre est appliqué exactement là où c’est nécessaire, pas globalement, afin de ne pas masquer autre chose par erreur.

À quoi cela ressemble

Le parcours, étape par étape.

L’inventaire : quels systèmes, quelles portes, quels droits

Quels systèmes sont en jeu, ce que chacun expose, qui a le droit de créer des credentials et qui les fait tourner. Pour chacun, la question de base : peut-on lire sans authentification ? Si oui, l’intégration devient beaucoup moins coûteuse et beaucoup plus facile à reproduire chez le deuxième client.

Le connecteur : outils déclarés, clés sur le serveur, délais

Chaque action devient un outil avec un nom, une description rédigée pour le modèle, des paramètres typés et son propre délai. Les clés restent dans l’environnement du serveur. À la fin, l’agent ne « sait pas faire » quelque chose de diffus : il dispose d’un ensemble fini d’actions, chacune avec ses limites.

Le test sur le cas qui échoue, pas seulement sur celui qui fonctionne

Un connecteur se teste sur la requête correcte, sur la requête incomplète, sur le système qui répond lentement et sur le système qui ne répond pas du tout. Ce que dit l’agent quand l’intégration échoue est une décision de conception, pas une erreur que découvre le client : nous préférons un message honnête et une prise en charge par un humain, plutôt qu’une improvisation plausible.

La résistance à l’instabilité de l’autre système

Nouvelle tentative avec des pauses croissantes, mais seulement pour les erreurs qu’il est logique de réessayer — une limitation de débit ou une erreur serveur, pas une requête incorrecte, qui sera incorrecte une deuxième fois aussi. Et lorsque le problème est au niveau du réseau de l’autre, le traitement est différent ; l’exemple ci-dessous est précisément un tel cas.

La passation : ce qui change lorsque le fournisseur change

Nous notons ce qui se casse si l’autre système change son API, quels credentials expirent et quand, ce qui doit être renouvelé manuellement. Une intégration sans cette liste est une dette cachée : elle fonctionne parfaitement jusqu’au jour où elle ne fonctionne plus et où personne ne sait pourquoi.

Les systèmes externes autour de la conversation : prises de rendez-vous, catalogue de la boutique, CRM, feuilles de calcul, SMS et canaux de messages — chacun lu à la demande, avec les clés restant sur le serveur.

Les données

Ce que nous touchons, où elles sont et combien de temps elles restent

Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.

Où se trouvent les credentials: Les clés de fournisseur de la plateforme se trouvent dans l’environnement du serveur, pas dans la base de données et jamais dans la page client. Les credentials propres à un client — là où l’intégration les exige — sont stockés chiffrés. La différence compte : une clé de plateforme compromise affecte tout le monde, un credential client affecte un compte ; nous les traitons différemment parce que le risque est différent.
Ce qui est stocké à partir des systèmes externes et ce qui ne l’est pas: Le catalogue de produits n’est pas copié : il est lu à la demande et conservé dans une mémoire temporaire de dix minutes, afin que dix questions consécutives sur le même magasin ne signifient pas dix parcours complets. Les programmations ne sont pas dupliquées chez nous — la source de vérité reste le système du salon. Ce que nous conservons, c’est la trace de la conversation et le résultat de l’action, pas une réplique de la base de l’autre système.
Ce qui parvient au modèle linguistique: Le résultat d’un outil entre dans la conversation, donc il entre aussi dans le contexte du modèle. C’est pourquoi le filtrage se fait sur le résultat, avant de le donner au modèle, et non dans les instructions. Les champs que le client n’a pas le droit d’entendre sont supprimés à la source ; ce qui a été supprimé ne peut pas être dicté, quelle que soit la manière dont l’agent est interrogé.
Qui peut lier une intégration: La connexion d’une intégration est une opération authentifiée, liée au compte de l’entreprise, et les outils résultants sont attachés à un agent précis — pas à tous. Un agent dispose exactement des outils dont il a besoin pour son rôle. C’est la même logique que pour l’accès d’un employé : on ne lui donne pas toutes les clés parce que c’est plus simple.
Ce qu’il reste à réparer, dit ouvertement: Tous les modules d’intégration de notre plateforme ne sont pas au même niveau. Ceux listés ici sont écrits et exécutés. Il existe aussi des modules commencés, de quelques dizaines de lignes, qui ne font encore rien d’utile — nous ne les présentons pas comme disponibles et nous ne les mettons dans aucune offre. Si vous avez besoin d’un système qui, chez nous, en est à ce stade, nous le traitons comme un travail à construire, avec une vérification de compatibilité préalable, et non comme une case à cocher.

Un cas

L’intégration tombait par intermittence, et ce n’était pas chez nous

La situation

Un connecteur CRM fonctionnait parfois et parfois non, sans schéma apparent au premier regard. Les requêtes restaient bloquées jusqu’à dépasser la limite d’exécution de l’environnement serveur, donc les journaux affichaient un dépassement de délai — le signe qui vous pousse, à tort, à chercher une lenteur dans votre propre code.

Ce que nous avons construit

La cause était sur le réseau, à l’autre bout. Le nom de domaine du compte CRM se résout en plusieurs adresses IP, et une partie des nœuds du cluster étaient en mauvais état. Une requête HTTP ordinaire choisit une adresse et, si celle-ci ne répond pas, n’essaie pas les autres adresses renvoyées par DNS — il n’y a pas de basculement automatique vers la réponse suivante. La correction a consisté à ne plus utiliser le client HTTP par défaut pour ce domaine : nous résolvons nous-mêmes le nom, ouvrons directement des connexions chiffrées vers chaque adresse en parallèle, avec un délai court sur chacune, et utilisons la première qui répond ; si toutes sont froides lors d’un tour, on recommence.

Ce qui en est sorti

Les interruptions intermittentes ont cessé d’être une loterie. Plus important pour le client : le diagnostic est devenu formulable en une phrase — « les nœuds du fournisseur sont indisponibles par intermittence, et nous les contournons » — au lieu de « parfois ça ne marche pas ».

Ce que le cas ne dit pas

C’est une correction qui compense un problème d’un autre, et il faut le dire. Elle ajoute de la complexité dans notre code pour un défaut de l’infrastructure du fournisseur ; si celui-ci répare son cluster, la complexité reste chez nous. Nous la documentons comme telle, afin qu’elle puisse être retirée lorsqu’elle ne sera plus nécessaire.

Questions

Ce que les gens nous demandent avant d'appeler

Quels systèmes avez-vous effectivement connectés, et pas seulement en théorie ?

Le système de réservations Altegio, avec six actions appelées par l’agent. amoCRM et Bitrix24, avec OAuth complet et rafraîchissement de jeton. Google Sheets, avec un compte de service dédié. Des boutiques WooCommerce, via l’API publique de la boutique. Telegram, pour les notifications. Infobip, pour les SMS. Le canal de chat d’une plateforme locale d’annonces. Plus les canaux de messagerie Meta et Telegram pour les conversations. Pour tout autre système — y compris des plateformes de boutique que nous n’avons pas menées jusqu’au bout — la réponse honnête est : sur demande, après une vérification de compatibilité, traitée comme un travail, pas comme un réglage.

Ma boutique doit-elle me générer des clés API ?

Pour WooCommerce, non. Nous utilisons l’API publique de la boutique, qui ne demande pas de clé de consommateur — vous vous connectez avec l’adresse du site. C’est aussi plus sûr, pas seulement plus simple : nous avons remplacé par cette approche des outils plus anciens qui gardaient des clés de boutique écrites en clair dans la base de données. Pour d’autres plateformes, cela dépend de ce qu’elles exposent ; nous vérifions avant de promettre.

L’agent peut-il faire une vraie réservation, et pas seulement dire qu’il le fait ?

Oui, si le système de réservations le permet. Il crée la réservation, peut l’annuler et la modifier, et vérifie la disponibilité avant. Un détail qu’on n’apprend que sur le terrain : dans ce système, le service et le spécialiste voyagent ensemble — si vous demandez les créneaux libres d’un spécialiste pour un service qu’il ne fait pas, vous obtenez zéro résultat, pas une erreur. C’est pourquoi l’outil de disponibilité renvoie tous les spécialistes qui font le service et les premiers créneaux libres pour chacun, afin que l’agent puisse proposer une alternative concrète.

Où vont mes clés ?

Les clés de plateforme restent dans l’environnement serveur, jamais dans la base de données et jamais dans votre page. Les identifiants qui vous appartiennent sont stockés chiffrés. La règle que nous appliquons : si une clé peut dépenser de l’argent ou peut lire des données pour tous les clients, elle n’a rien à faire là où arrive du code exécuté à la demande d’un modèle linguistique.

L’agent peut-il envoyer des SMS à qui il veut ?

Non, et c’est une restriction délibérée. En mode de notification à l’entreprise, le destinataire vient de la configuration — le modèle ne peut pas le choisir. En mode vers le client, le numéro est normalisé et validé. En plus de cela, il existe un plafond journalier par agent, une pause d’une minute vers le même numéro et une limite de longueur du message. Ce sont des gardes dans le code, pas des instructions dans le prompt ; un prompt peut être contourné par la conversation, pas une garde.

Que se passe-t-il quand le système de l’autre tombe en panne ou répond lentement ?

Chaque outil a son propre délai d’exécution, afin qu’un système lent ne bloque pas la conversation. Nous réessayons avec des pauses croissantes, mais seulement sur les erreurs qui méritent d’être réessayées — une limitation de débit ou une erreur de serveur, pas une mauvaise requête. Et le comportement de l’agent en cas d’échec est écrit dans le scénario : il dit qu’il ne peut pas vérifier maintenant et passe la discussion à quelqu’un d’autre, au lieu d’inventer une réponse plausible.

Que se passe-t-il si le fournisseur change son API ?

Quelque chose casse, et c’est pourquoi nous préférons les portes officielles à la lecture des pages. Les outils qui extraient l’information du HTML d’un site se cassent à chaque changement de thème — nous les avons délibérément remplacés par une seule implémentation au-dessus de l’API officielle, justement pour ne pas entretenir des dizaines de variantes fragiles. Quand il n’existe pas d’alternative, nous disons que c’est une solution fragile et nous la traitons comme telle.

Pouvez-vous faire des automatisations sans agent, seulement avec des règles programmées ?

Oui. La reprise des conversations restées sans réponse, le premier message vers un nouveau contact, l’arrêt et le redémarrage de l’agent selon l’horaire de travail — ce sont des tâches programmées qui s’exécutent toutes seules. Chacune a ses propres compteurs pour les exécutions, les messages envoyés, les messages sautés et les erreurs, afin de pouvoir répondre à la question « a-t-il tourné ? » avec un chiffre, et non avec une supposition.

Comment vous assurez-vous que l’agent ne dise pas ce qu’il ne faut pas, à cause d’une intégration ?

Nous filtrons le résultat avant qu’il n’arrive au modèle, pas après. Le cas concret que nous avons résolu : la politique d’un client interdisait que l’agent dicte le numéro de téléphone du chauffeur, mais l’API renvoyait ces numéros. Nous avons écrit un filtre qui parcourt récursivement la réponse de l’outil et retire les champs de contact du chauffeur, en conservant les numéros du dispatch, appliqué exactement à l’outil concerné. Ce qui n’arrive pas au modèle ne peut pas être énoncé, quelle que soit la manière dont l’agent est interrogé.

Sur quoi reposent les affirmations ci-dessus (18 sources)

18 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.

Comment nous travaillons Tous les services

Qu'est-ce que vous voudriez voir mieux fonctionner ?

Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.

Discutons