Quatre projets, expliqués en détail.

• Chat Trigger n8n (auto-hébergé) : le point d'entrée de chaque conversation.
• AI Agent en tool-calling (OpenAI) : c'est le modèle qui décide s'il faut appeler un outil, et lequel.
• RAG agentique : la recherche dans les politiques est un outil que l'agent choisit d'utiliser, pas une étape forcée à chaque message. Un « bonjour » ou un numéro de commande ne déclenche pas de recherche documentaire inutile.
• Même modèle d'embedding à l'ingestion et à la recherche : documents et questions sont vectorisés par le même modèle — sinon les vecteurs ne sont pas comparables et la recherche renvoie du bruit.
• Outil de recherche de commande : lecture en direct dans Google Sheets à partir du numéro de commande.
• Outil d'escalade : écrit la demande (type, commande, résumé) dans un journal dédié, traité par l'équipe humaine.
• Mémoire par session : les questions de suivi (« et elle arrive quand ? ») gardent leur contexte.
• Cadrage anti-invention : l'agent répond uniquement à partir des résultats de ses outils ; si l'information manque, il le dit.

Testé de bout en bout sur trois familles de scénarios — recherche de commande, question de politique et escalade :

Tests effectués par moi sur une boutique de démonstration, avec des commandes fictives : ce n'est pas un audit externe.

Ce que ça prouve : un agent utile en support n'est pas celui qui répond à tout — c'est celui qui sait quand ne pas répondre, et qui laisse une trace quand il passe la main.

• Il répond à partir des informations de l'école (RAG) : inscription, tarifs, financement, code, leçons, examen, horaires…
• Il n'invente jamais : si la réponse n'est pas dans les informations de l'école, il le dit.
• Il capte les leads : un prénom et des coordonnées, puis une personne de l'équipe rappelle.
• Il prend les rendez-vous dans Google Calendar et refuse les créneaux déjà pris.
• Il protège les données personnelles : aucun accès aux dossiers des élèves.

Assistant construit pour une auto-école fictive, comme démonstration de ce que je livre aux vraies auto-écoles.

1. Complétude
2. Doublon (HubSpot)
3. Format du numéro
4. Numéro réel (Numverify)
5. Email délivrable

• Webhook Make.com exécuté dès l'arrivée des données, puis normalisation des champs et formatage du numéro avant tout contrôle.
• Contrôles en cascade, du moins coûteux au plus coûteux : les vérifications gratuites (champs manquants, doublon dans HubSpot, format) passent avant les appels d'API payants. Un lead incomplet ne consomme jamais de crédit de vérification.
• Un routeur par contrôle : chaque sortie en échec écrit une ligne dans le journal, avec le type d'échec et la raison.
• Résilience aux pannes d'API : si le service de vérification du téléphone ou de l'email ne répond pas, le lead n'est pas perdu. Il est créé dans HubSpot avec le statut « à revérifier », une alerte email part, l'erreur est journalisée, et une directive Resume permet au scénario de continuer. Le compromis est assumé : pendant une panne, un lead non vérifié entre dans le CRM — mais marqué, donc facile à revérifier ensuite.
• Classeur Google Sheets structuré : Lead Log, Dashboard, Config, Errors, Alerts Sent — plus un onglet Read Me et un guide d'installation pour la passation.

Sur un jeu de test de 45 leads simulant des soumissions publicitaires :

Données de test que j'ai créées moi-même pour éprouver le pipeline (format britannique : numéros 07…, livres sterling). Aucune donnée client réelle, aucun chiffre client à communiquer.

Chaque rejet porte une raison lisible : Not a valid UK mobile number format, Number not in service (carrier check failed), Disposable email address, Already exists in HubSpot CRM, Phone number field left empty.

Ce que ça prouve : une gestion d'erreurs de niveau production. Une panne d'API ne fait perdre aucun lead, et chaque décision du système est traçable.

Deux minutes, sur une soumission de formulaire réelle envoyée dans le système : un faux numéro bloqué et journalisé, puis un lead valide synchronisé dans HubSpot en temps réel. (Vidéo en anglais, enregistrée sur la version britannique du projet.)

• Webhook Tally → Make.com : le scénario démarre à l'envoi du formulaire.
• OpenAI (gpt-4o-mini), cadré par un schéma JSON défini dans le prompt système : score, secteur, budget_estime, urgence, resume, signaux_positifs, signaux_negatifs, action_recommandee — avec des valeurs énumérées (« Faible » | « Moyen » | « Élevé » | « Inconnu »). L'IA ne produit pas du texte libre, mais des données qu'un workflow peut exploiter.
• Parsing JSON puis normalisation des variables avant toute décision. Le schéma est imposé par le prompt, pas par l'API : c'est le parsing qui vérifie que la sortie est exploitable.
• Routeur en trois branches, détaillé ci-dessous.
• Propriétés personnalisées dans HubSpot (Score IA, Résumé IA, Urgence) : les commerciaux trient directement dans leur CRM.
• Gestion d'erreurs sur l'appel OpenAI : en cas d'échec, email d'alerte puis directive Resume — le scénario ne s'arrête pas.

Sur une série de 9 demandes de test, du projet précis à la demande vague :

« Agence Meridio » est une agence fictive que j'ai créée pour construire et éprouver ce pipeline. Les demandes, les noms et les scores ci-dessous sont des données de test.

Les 9 demandes, sans tri. La route est calculée à partir du score ; l'action recommandée est un avis séparé de l'IA. Les deux sont enregistrés et peuvent diverger, comme sur les lignes 70 et 60.

Ce que ça prouve : savoir utiliser un modèle de langage comme un composant fiable d'un système — sortie structurée, valeurs contrôlées, et gestion d'erreurs quand le modèle échoue.

Les captures ci-dessus viennent du système réel. Vous voulez le voir tourner sur une demande que vous écrivez vous-même ? Je vous en fais la démonstration en direct.