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à construitIntegrări proprii, scrise și rulate, măsurate azi în cod: conectorul pentru sistemul de programări Altegio (946 de linii, cu șase unelte expuse agentului), conectorul de CRM amoCRM (2.888 de linii în platforma de mesagerie, plus 12 funcții de server în platforma vocală), Bitrix24 (903 linii, plus 4 funcții), Google Sheets (615 linii, plus 10 funcții și un cont de serviciu dedicat), catalogul viu peste magazin (serviciu de platformă, 318 linii), notificări de lead pe Telegram (1.776 de linii), SMS prin Infobip cu limite anti-abuz, automatizări programate (1.088 de linii) și canalul de chat al unei platforme locale de anunțuri (2.459 de linii). În execuție, agentul poate chema 15 tipuri de unelte interne, pe lângă unelte prin webhook și unelte cu cod propriu rulat în izolare.

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.

Automatizare transparentă — integrări care se pot verifica · video în română, cu subtitrare și transcriere

Transcrierea completă

Să intrăm direct în subiect. Astăzi vom diseca realitățile tehnice și, sincer, adesea ignorate, ale automatizării prin asistenți bazați pe inteligență artificială. Ne vom concentra pe o abordare super pragmatică a platformei iCat.md dezvoltată de Mega Promoting. Nu avem promisiuni de marketing astăzi și, cu siguranță, nu avem concepte vagi. Discutăm despre o platformă aflată direct în producție, cu funcționalități explicate direct din arhitectura bazei de date. Așa că haideți să vedem cum arată, de fapt, automatizarea complet transparentă. Agenda acestei analize este simplă și la obiect. Trecem prin problema timpului, mecanica tehnologiei, un caz real, limitele clare ale sistemului, managementul datelor și pașii următori. Începem cu prima secțiune, problema timpului. Știți cu toții acea întrebare extrem de frustrantă? De ce o întreagă echipă de suport pierde ore bune, zi de zi, scriind de mână răspunsuri la fix aceleași cinci întrebări? Informația există deja pe site-ul companiei, dar, cu toate astea, clienții continuă să ceară detaliile în mod repetat. Și exact asta este esența problemei noastre. Fără o soluție tehnică potrivită, toate aceste solicitări repetitive pur și simplu înfundă mesageria directă, nu contează dacă e Instagram sau Messenger. În consecința, răspunsurile întârzie masiv pentru clienții care au cu adevărat o problemă complexă, cererile se rătăcesc în marea de mesaje, iar întregul proces de suport devine practic o cutie neagră pe care nu o poți nici verifica, nici măsura. Partea a doua. Cum funcționează, de fapt, tehnologia sub capotă? Uite care-i treaba. Setarea platformei se bazează pe patru pași foarte logici. Mai întâi conectăm canalele de comunicare folosind cod propriu. Apoi se indexează toată baza de cunoștințe. Urmează legarea uneltelor care pot executa acțiuni în sistemele voastre existente. Iar la final, și acest detaliu este vital, se configurează un traseu clar înregistrat direct în baza de date prin care botul predă discuția unui operator uman. Totul este un sistem vizibil și perfect configurabil. Acum, un aspect absolut fascinant. Nu vorbim din plian de aici. Acestea sunt setări extrase direct din schema bazei de date. Când asistentul are nevoie de un răspuns, el folosește o așa numită căutare hibridă. Implicit, algoritmul extrage 5 fragmente de text, aplică un prag strict de similitudine de 0-70 și acordă o importanță de 30% potrivirii exacte a cuvintelor. Totul este procesat prin modelul Text Embedding 3 Small. Practic, sistemul transformă cuvintele în concepte matematice pentru a prinde contextul exact. Răspunsurile nu sunt oghicitoare, ci matematică pură. Rețineți acest număr. 15. Este o limită tehnică absolută în sistem. Reprezintă timpul maxim, în secunde, alocat pentru a rula orice unealtă sau căutare. Dacă o integrare externă durează mai mult de atât, să zicem că are nevoie de 40 de secunde, nu o putem lăsa în fluxul live-a conversației. Ea trebuie procesată asincron, altfel s-ar rupe complet ritmul natural al dialogului. Și mai e ceva. Oamenii scriu pe chat în rafale, nu? 2, 3, 4 mesaje scurte trimise unul după altul. Pentru a nu înnebuni sistemul, există un tampon de concatenare de 15 secunde. Tot ce intră în această fereastră se lipește și devine o singură cerere clară. Mai mult, pe platforme ca Meta, unde uneori te lovești de mesaje duplicate trimise din eroare, sistemul aplică un filtru de memorie de 120 de secunde pe ID-ul mesajului. Astfel, clientul primește un singur răspuns coerent, nu 3 alarme false. Secțiunea a treia. Să vedem un caz real. Avem acest scenariu clasic de e-commerce. Avem un magazin online, cu un catalog impecabil pe site, dar care primește o avalanșă de mesaje private pe Instagram și Messenger? Mai e în stoc? Ce preț are? Aici integrarea s-a făcut elegant, conectând asistentul direct la interfața publică Store API de la WooCommerce. Fără complicații de securitate, catalogul viu al magazinului a fost pur și simplu pus în mânile asistentului. Doar aici intervine realitatea tehnică a fiecărei platforme, chiar și sub umbrela aceleiași companii, cum e Meta. Pe Messenger, asistentul vă poate arăta carusele de produse superbe. Pe Instagram, botul o să vă răspundă doar cu text și cel mult o imagine simplă. De ce? Pur și simplu pentru că Meta nu suportă acele șabloane generice pe Instagram. Asistentul trebuie să joace exact după regulile canalului unde se află. Aici este punctul critic. Ce se întâmplă când botul este depășit de situație? Ei bine, în baza de date conversația are stări explicite. Când o întrebare iese din zona de confort a catalogului, firul de discuție trece imediat din starea bot în starea umană. Și partea genială e că sistemul contorizează timpul în care răspundă operatorul uman, marcând totul clar, status OK, avertiziment sau termen depășit. Tot contextul este predat omului, fără să se piarda absolut nimic pe drum. Secțiunea A4 Limitele sistemului Pentru că transparența înseamnă să știm ce nu poate face. Sunt câteva limite ferme pe care trebuie să le acceptăm. Nu puteți trimite mesaje proactive pe WhatsApp dacă au trecut mai mult de 24 de ore de la mesajul clientului. Meta va trânti o eroare, mai exact eroarea 131047, iar acțiunea va eșua. Sistemul nu face fișie RPDF, nu citește atașamente. La partea de limbi străine, traducerile merg doar într-un singur sens. Clientul primește răspunsul tradus, dar operatorul vede originalul. Și, deși integrarea cu 999.md funcționează, este neoficială și se bazează pe cookie-urile din browser. Dacă platforma își modifică mecanismele, conexiunea cade și necesită reparații. Și rețineți neapărat asta. Asistentul este oglinda datelor voastre. Un preț greșit pe site va deveni garantat un preț greșit în conversație. El acționează ca un cititor, nu ca un manager de magazin. Nu va corecta din proprie inițiativă erorile umane din cataloge. Infrastructura tehnică de aici nu e o joacă. Totul este ținut pe un server privat Microsoft Azure. Discutăm despre o bază de date MySQL extrem de structurată, cu peste 80 de tabele modelate clar pentru a separa canalele și pentru audit. Cheile de acces pentru WhatsApp, care sunt supersensibile, folosesc criptare fernet. Pe lângă asta, la nivel de web, domeniile pentru widgetul de chat sunt adăugate manual într-o listă albă. Nimeni nu se conectează fără permisiune explicită. Trebuie însă să abordăm o realitate evidentă. Oamenii vor scrie tot felul de date personale în acele ferestre de chat, numere de telefon, adrese. Tehnic, nu ai cum să blochezi un câmp de text liber. Așa că soluția este administrativă. Când implementați un astfel de sistem, aveți nevoie, din secunda 1, de politici clare de retenție care să dicteze exact cine are voie să vadă acele date și pentru cât timp sunt stocate. Și am ajuns la punctul 6. Pașimul mători. Filozofia centrală a întregului sistem poate fi rezumată prin acest citat. Un asistent utim nu este cel care compune poezii sau scrie frumos, ci acela care este conectat la informații reale și, foarte important, știe exact unde trebuie să se oprească. Automatizarea eficientă în business înseamnă preluarea corectă a datelor și siguranța cu care cedes controlul unui operator uman la momentul oportun. Prin urmare, pasul următor nu este să cumpărați un soft, ci să vă analizați cu atenție procesele actuale. Evaluați ce fluxuri de lucru merită cu adevărat să fie construite și automatizate, cum se pot conecta ele în siguranță și, cel mai important, stabiliți cum veți măsura rezultatele cu date reale, nu cu iluzii de marketing. Și vă las cu această temă de gândire. Dintre toate procesele de comunicare dintr-o afacere, care sunt acelea care necesită cu adevărat empatia și tactul unui om și care sunt, de fapt, doar sarcinii repetitive ce așteaptă pur și simplu să fie conectate cu precizie la baza de date corectă? Orice plan de automatizare ar trebui să plece de la această întrebare. Mulțumim că ați fost alături de noi în această analiză!

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.

Sistemele externe din jurul conversației: programări, catalogul magazinului, CRM, foi de calcul, SMS și canale de mesaje — fiecare citit la cerere, cu cheile rămase pe server.

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