Chaque système que j'ai construit a commencé par un chiffre que l'entreprise voulait faire bouger : tickets par jour, leads par mois, sites par mois, minutes avant la première réponse. L'architecture suit le chiffre, pas l'inverse.

Prompt, retrieval, orchestration, intégrations, serveurs, sécurité, documentation. Si ça tourne en production, c'est à moi jusqu'à ce que ce soit monitoré, testé et transmis avec les documents dont la personne suivante a besoin.

Évaluations Langfuse sur le retrieval et les réponses, CSAT, comparaison de chaque nouvelle version d'un flux avec la précédente avant mise en production, et une boucle d'amélioration hebdomadaire sur les conversations réelles. Un score RAG passé de moins de 0,6 à 0,9 : voilà le genre de preuve que je cherche.

Avant de construire, je regarde le meilleur produit de la catégorie, Intercom pour le widget de support, Zendesk pour le CRM, et j'écris ce que le battre signifie pour ce client. Puis les blocs, les jalons et les tests QA suivent cette liste.

Une cinquantaine d'agents de support traitaient à la main environ 4 000 tickets par jour, avec des pics de plus d'une centaine de conversations en cinq à dix minutes. En surcharge, la première réponse prenait jusqu'à 18 minutes et la satisfaction client plafonnait à 2,5 sur 5. Chaque ticket, même le plus trivial, coûtait du temps humain, et le savoir nécessaire pour répondre était dispersé entre le CRM et des années d'historique de messages. Le brief : un widget qui répond seul à la majorité des tickets, dans la langue du client, et ne laisse aux humains que les cas qui demandent du jugement. Le benchmark que je me suis fixé avant de construire : Intercom.

Un widget de chat sur le site du client, déployé via Google Tag Manager, qui comprend la demande dans n'importe quelle langue, consulte le compte du client s'il est connecté, répond à partir d'une base de connaissances construite sur le CRM et l'historique de messages du client, et transfère les cas complexes à un humain dans Zendesk avec la transcription complète et le contexte du compte. n8n orchestre les flux principal, d'escalade et de reporting ; LangGraph exécute la logique cyclique par intention, de sorte que le graphe décide pas à pas s'il faut répondre, demander, vérifier ou escalader. Chaque agent a son propre prompt, GPT-4o mini comme modèle principal et Gemini 2.5 via OpenRouter en secours. Pinecone héberge la base de connaissances, MongoDB la mémoire partagée, Redis le cache. J'ai installé et durci les serveurs moi-même : tout tourne sous Docker sur l'infrastructure propre du projet, avec un monitoring des serveurs et de chaque nœud n8n pour que les bugs remontent avant que le métier ne les voie.

• Un prompt, un modèle principal et un modèle de secours par agent. Le widget lui-même a une version de secours pour quand le chemin IA est hors service.
• GPT-4o mini pour le coût et la latence : réponse moyenne ~3 s, longues conversations plafonnées autour de 7 s, pic à 9 s.
• La mémoire partagée dans MongoDB alimente une boucle d'amélioration hebdomadaire sur trafic réel : qualité des réponses, prompts, CSAT, sécurité du LLM.
• Chaque nouvelle version d'un flux est comparée à la précédente avant mise en production, nœud par nœud, pour repérer les changements de comportement avant que les clients ne les voient.
• Vision et OCR : un client envoie une photo, un reçu par exemple ; les données sont extraites, stockées dans MongoDB et utilisées par les agents.

• Serveurs construits et durcis de zéro ; le chemin des données entre orchestrateur, serveur et navigateur est protégé de bout en bout.
• Tests d'intrusion menés par des agents que j'ai construits avec des règles fondées sur le modèle de permissions, tests en boîte grise sur l'API, la latence et les points d'entrée de l'infrastructure, revue par l'équipe sécurité interne et test en boîte noire par une société externe. Chaque faille corrigée par moi.
• Défense contre l'injection de prompt et contrôle de ce qui atteint le modèle ; les données sensibles ne quittent jamais le périmètre sans raison.

• Projet en solo, plus de six mois jusqu'à la mise en production, découpé en blocs : chaque bloc livré avec sa propre QA, son monitoring et sa documentation.
• Toutes les automatisations versionnées sur GitHub avec des pipelines CI/CD.
• Livrables finaux : documentation de l'API, un playbook pour l'équipe du service client et le document technique du projet.

L'équipe de support de 50 personnes n'a pas été supprimée. Elle a été formée au nouveau flux et en partie proposée à d'autres entreprises comme service : l'entreprise a transformé un centre de coûts en nouvelle source de revenus.

Migration vers Qwen 3 de Hugging Face avec Qdrant, construite avec les équipes ML et DevOps, pour la confidentialité, la latence, le contrôle et la possibilité d'améliorer le modèle. Le modèle local sert aussi de filtre sur les données envoyées aux LLM externes. Fine-tuning en préparation ; ensuite le même modèle servira les équipes internes et le widget lui-même.

Les marques avaient besoin de dizaines de sites web chaque mois pour développer leur présence et envoyer du trafic vers la page principale : des sites satellites autour d'une ou deux marques, chacun assez spécifique pour être indexé et lu. Il n'y avait pas d'équipe de contenu pour les rechercher, les rédiger, les concevoir, les illustrer et les construire, et chaque site devait être assez spécifique pour être indexé et assez peu coûteux pour en produire des dizaines par mois.

Un pipeline d'agents Hermes, auto-hébergés sur le serveur de l'entreprise, avec un agent dédié à la recherche, un au scraping et à la composition, un au design, et un script final qui publie. Deux points d'entrée. Depuis une URL d'exemple : les agents recherchent et scrapent un site similaire et en composent un nouveau qui s'en inspire. Depuis zéro : la demande entre via MCP depuis Claude Code ou Codex, la recherche tourne sur Perplexity et l'Anthropic API, le système scrape ce que l'opérateur a demandé, puis mène un court entretien pour recueillir les faits que seul un humain connaît, et construit le site. GPT-6 Astra génère les images. Un clic clone un site avec un design légèrement différent, ou complètement différent. Une base de données de chaque exécution grandit avec l'usage et améliore le second mode au fil du temps. La sortie est du HTML statique, exporté et déployé sur les serveurs du client via le script DevOps.

Les templates donnent le même site à chaque fois, et les moteurs de recherche le savent. Les agents recherchent le sujet, interrogent l'opérateur et écrivent pour ce sujet, donc chaque site est spécifique, lisible et indexable. Le coût reste proche de cinq euros parce que les étapes coûteuses, recherche et images, sont mises en cache dans la base des exécutions et réutilisées.

• Recherche de mots-clés et correspondance mot-clé / page ; balises title et meta descriptions ; hiérarchie H1, H2, H3.
• URL propres, balises canoniques, sitemap.xml, robots.txt ; maillage interne.
• Textes alternatifs et images légères, optimisées pour le crawl ; Core Web Vitals ; mobile first.
• Données structurées en JSON-LD schema.org ; Open Graph.
• GEO, Generative Engine Optimization : sections FAQ et llms.txt pour que les moteurs de recherche IA puissent lire et citer le site ; hreflang pour les sites multilingues.

Une centaine de sites par mois, cinq à dix minutes chacun, environ cinq euros par site. Les sites sont des satellites d'une ou deux marques et envoient du trafic vers la page principale de la marque ; le trafic est suivi au niveau de la marque.

Le support, les ventes et la direction travaillaient sur des outils séparés et voyaient le même client sous des angles différents. Les événements métier, signaux de fraude, paiements et remboursements, comptes bloqués, activité des affiliés et des influenceurs, atteignaient les gens en retard, par des rapports, au lieu de l'instant où ils se produisaient. Le brief : une plateforme unique pour les trois équipes, avec Zendesk comme benchmark à battre, construite sur les serveurs de l'entreprise.

Une plateforme unique pour le support, les ventes et la direction : les mêmes clients, des alertes en temps réel, voix, SMS et Telegram depuis un seul écran, une base de connaissances dans le style de Notion intégrée au produit, de l'analytique sur AWS et Tableau, et une couche IA qui route les demandes et répond à partir de la base de connaissances. Architecture définie avec le DevOps, le département développement, le PM et le Quality Manager du client ; microservices Kubernetes sur les serveurs de l'entreprise, un service par moteur, front-end entièrement en TypeScript avec des parties en Java. Je dirige trois ingénieurs IA : sprints de deux semaines avec une réserve d'une dizaine d'heures pour les correctifs urgents, test QA à la fin de chaque jalon face au benchmark, améliorations en asynchrone, gestion des blocages, résolution quotidienne des problèmes avec le service client, le Quality Manager et le responsable QA.

• Backend et front-end.
• Gestion des accès : rôles et permissions.
• Espace de travail pour les opérateurs du support.
• Analytique connectée à AWS et à un espace Tableau.
• Alertes métier intégrées au CRM à partir des données des départements sur AWS.
• Alertes en temps réel via Kafka, construites avec un ingénieur ML.
• Base de connaissances intégrée, voix et SMS via Voiso, Telegram pour la communication client.

Des blocs avec des jalons ; un test QA à la fin de chaque jalon et une comparaison avec le benchmark ; améliorations traitées en asynchrone ; blocages levés chaque jour. Sprints de deux semaines par ingénieur, état d'esprit Agile, et une petite réserve dans chaque sprint pour ce qui casse.

Un agent avec routage intelligent, une base de connaissances avec recherche sémantique, et une extension de navigateur de l'agent qui exécute les tâches routinières pour les opérateurs. Le CRM sert le service client, la direction et les ventes, donc le même agent travaille sur les demandes de support et sur la production de leads.

Un LLM on-premise (Qwen 3) avec accès complet aux données du CRM et à la plateforme interne de données client ; un agent avec sa propre base de connaissances qui aide le support à répondre plus vite ; l'extension de navigateur par laquelle le support définit des actions qui s'exécutent automatiquement pour le client.

Les employés posaient chaque jour les mêmes questions routinières aux RH, à la Finance et au Juridique : jours de congé, plafonds de dépenses, quel modèle utiliser. Chaque réponse prenait du temps aux personnes qui devaient la donner, et le savoir vivait dans des documents que personne n'ouvrait. Sur le site web de l'entreprise, les visiteurs n'avaient ni self-service ni moyen simple de laisser une demande. L'entreprise vivait déjà dans Microsoft 365 : la réponse devait donc y vivre aussi.

Un assistant par département, dans le canal Teams où les gens travaillent déjà. L'agent RH détient tout le savoir RH partagé, répond aux questions fréquentes et journalise tout ; la Finance et le Juridique suivent la même logique. Agents construits dans Microsoft Copilot Studio, ancrés sur les documents SharePoint, avec Azure OpenAI pour les modèles et Databricks pour les logs, le partage de données et l'amélioration continue. La même stack alimente un assistant sur le site web de l'entreprise : informations générales, connecté directement à SharePoint et Databricks, avec une étape lead qui invite le visiteur à envoyer sa demande par e-mail quand la conversation montre une intention. Construit juste après le widget de support, seul, pour une partie prenante interne d'Acrh Software.

Le client vivait déjà dans Microsoft 365 : Teams, SharePoint, Azure. Construire là où les gens sont déjà a supprimé la friction d'adoption ; personne n'a dû apprendre un nouvel outil. L'ancrage sur SharePoint garde chaque réponse sourcée et auditable, et Databricks conserve les logs qui alimentent la boucle d'amélioration.

• RH : congés, politiques, questions d'onboarding, avec tout le savoir RH partagé derrière.
• Finance : règles de dépenses, plafonds, procédures.
• Juridique : modèles, versions, quand une clause nécessite une revue humaine.
• Chaque conversation journalisée, pour que les départements voient ce que les gens demandent vraiment et corrigent les documents, pas seulement les réponses.

L'assistant répond d'abord et ne demande la requête par e-mail que lorsque le visiteur montre une intention d'achat. Les leads arrivent aux ventes avec la conversation jointe, donc la première réponse humaine connaît déjà le contexte.

Les leads arrivaient par e-mail et étaient lus en retard. Cinq managers commerciaux passaient leur journée en qualification routinière, à copier des noms et des numéros de téléphone, et perdaient des acheteurs déjà partis chez l'agence suivante. Le client voulait une innovation visible sur le site web et, surtout, des leads qui arrivent propres et obtiennent une réponse immédiate.

Un widget conversationnel intégré au site du client avec toutes les informations sur les biens et immeubles en vente. Le code et le prompt du bot vivent sur Replit, OpenAI est le modèle, la conversation est conçue dans Voiceflow, Airtable est le CRM, Make exécute les automatisations. Le widget recueille le nom, le téléphone et l'e-mail de l'acheteur, le champ clé. Flux un : dès qu'un lead est enregistré, le manager reçoit une notification Telegram avec le lead. Flux deux : l'acheteur reçoit un e-mail personnalisé avec les disponibilités correspondant à sa demande et un bouton pour prendre rendez-vous. Flux trois : le clic ouvre une demande dans le Google Calendar et Meet du manager, le manager accepte, l'acheteur reçoit la confirmation. Des messages proactifs se déclenchent quand le visiteur clique sur des boutons clés, ce qui a fait gagner cinq points de leads supplémentaires.

L'e-mail était le champ clé : la relance avec les biens correspondants faisait la vente pendant que le manager était occupé. Les messages proactifs sur les clics clés, simulateur de crédit, plan d'étage, ont ajouté cinq points de leads à eux seuls. Et les managers ont cessé de copier les données à la main, parce qu'elles arrivaient déjà structurées.

• Automatisations de contenu et de publication automatique sur Facebook, Instagram, VK et X via Make, pour l'agence et pour des clients.
• Toute la façon de travailler de l'agence reconstruite dans ClickUp pendant que l'équipe passait de 50 à 200 personnes : intégrations RH avec onboarding et offboarding automatiques, analytique du CRM client dans ClickUp, conversations structurées avec rôles et permissions, un gestionnaire de tâches et une plateforme sur mesure de planification et de réunions.
• Plus de 20 sites web clients construits de bout en bout en JavaScript, Next.js et Astro, avec des connexions API au CRM, déployés sur les serveurs des clients.

Les clients devaient répondre à leurs clients à toute heure et qualifier chaque contact sans embaucher. Les conversations explosaient à chaque campagne publicitaire, et un message manqué était un client perdu. C'était la réalisation la plus demandée à l'agence, et chaque client avait une partie prenante différente, un canal différent et une définition différente du bon lead.

Un bot qui démarre sur un mot-clé sur WhatsApp, Instagram ou Telegram, exécute un flux défini avec un LLM à l'intérieur, qualifie le contact avec un prompt précis écrit pour ce client, et le classe dans un CRM sur mesure construit en Google Apps Script, où le lead passe de froid à tiède puis chaud au fil des étapes accomplies. Les bots servaient à la fois le service client, en dialoguant directement avec l'utilisateur final, et le support de l'équipe du client. À partir de 2022, les mêmes clients ont eu des agents vocaux : une réceptionniste vocale et un agent RH qui recueille les données des candidats, construits sur Twilio et ElevenLabs ; des agents sortants sur Vapi et Retell qui appellent les leads des listes du client et posent les questions de qualification. Orchestration dans Make et n8n avec du code sur mesure ; modèles d'OpenAI, Anthropic et OpenRouter.

• Un prompt par client, avec les critères de qualification écrits comme questions explicites, jamais laissés au jugement du modèle.
• Les stades du pipeline ne changent que sur étapes accomplies : un lead ne peut pas devenir chaud sans coordonnées.
• Chaque bot tourne 24h/24, 7j/7 ; quand une campagne explose, les conversations augmentent sans qu'aucun canal reste sans réponse.

• Réceptionniste vocale sur Twilio et ElevenLabs : répond, oriente, prend le message.
• Agent vocal RH : recueille les données des candidats dans une conversation qui suit le prompt.
• Agents sortants sur Vapi et Retell : appellent les leads, posent les questions de qualification, transmettent le résultat au CRM.
• Un agent Ventes, et un agent Finance qui traite des données internes, sur la même orchestration.

Groupe automobile à Rome, plus de 1 000 employés, une flotte d'environ 200 000 véhicules. Tableaux de bord KPI Power BI construits sur SQL, des extractions AWS et des API internes avec le département IT, pour tout le département commercial et pour la direction avec alertes. Stock dormant réduit de 25 % parce que les données circulaient plus vite et que les véhicules d'occasion se vendaient plus tôt. Contrôle des KPI et des factures d'un fournisseur pesant deux à trois millions d'euros par an. Quatre nouveaux analystes intégrés et formés.