Du temps rendu à vos équipes
Le travail qui revient chaque semaine est pris en charge par une IA qui tourne en production : trier les e-mails, classer les demandes, ressaisir, trancher les cas simples. Les cas incertains remontent à une personne de votre équipe. Vos équipes consacrent ce temps aux dossiers qui comptent, gardent la main sur les décisions, et le résultat est mesuré.
Je branche l’IA sur vos outils
Votre CRM, votre messagerie, vos fichiers Excel, votre logiciel métier : l’automatisation par l’IA se branche sur ce que vos équipes utilisent déjà. Vous gardez ce qui marche, sans tout refaire ni changer d’habitudes. Les e-mails arrivent rattachés au bon dossier, les demandes sont classées, et les réponses sont préparées dans l’outil où vous les relisez.
Comment je m’y prends : l’automatisation IA en cinq étapes
Cinq étapes, toujours dans le même ordre. Chacune se termine par quelque chose que vous voyez et que vous validez.
1. Vos sources
Je pars de là où vos informations arrivent aujourd’hui : boîtes e-mail, formulaires, CRM, tableurs, logiciel métier. On choisit ensemble le cas qui coûte le plus de temps, et on écrit ce qui sera automatisé et ce qui reste entre vos mains.
2. Un format commun
Chaque source parle sa langue. Je la traduis dans un format commun et vérifié, pour que l’IA travaille sur des données propres et que chaque chiffre se retrouve à sa source.
3. Les flux
Qui reçoit quoi, quand, et qui décide. L’IA trie, classe et prépare ; sous un seuil de confiance, le cas passe à une personne de votre équipe, et sa correction améliore la suite.
4. Les pannes prévues
Un service qui ne répond pas, un fichier mal formé, un partenaire en retard : chaque panne a sa réponse écrite avant la mise en production. Rien ne se perd, rien ne part en double.
5. La sécurité et l’exploitation
Droits accordés personne par personne, environnements séparés, journal des décisions. Puis la surveillance au quotidien : je suis alerté en cas d’incident, et le résultat est mesuré.
Un humain au bout de la chaîne
L’IA propose, vous décidez : rien ne part sans votre accord. Quand le modèle est sûr de lui, le travail arrive prêt à valider ; en dessous d’un seuil de confiance que vous fixez, le cas remonte à une personne de votre équipe. Chaque correction sert d’exemple, et le modèle apprend de votre pratique réelle.
Et si ça plante ?
Une automatisation en production doit tenir les jours où un service tombe. Je la construis pour cela :
- Les demandes passent par une file d’attente : si un service ne répond plus, elles attendent leur tour au lieu de se perdre.
- La reprise est automatique : un nouvel essai part après quelques minutes, puis à intervalle croissant, sans que personne ait à relancer.
- Une commande ou un paiement n’est jamais passé en double, même si la connexion coupe au mauvais moment.
- Ce qui échoue encore est mis de côté, visible, et je reçois une alerte. Une fois la cause corrigée, c’est relancé : rien n’est oublié.
- Un contrôle quotidien compare vos données à celles de vos partenaires et signale chaque écart.
Le détail technique est plus bas, dans Sous le capot.
Vos données restent sous votre contrôle
Vous savez où sont vos données. Lumineth Hub tourne chez AWS à Paris, dans l’Union européenne, avec une base par site ; votre site public peut être hébergé en Suisse ; le modèle d’IA peut être appelé depuis Zurich, avec un traitement limité aux régions européennes. Aucune donnée personnelle ne part vers le modèle sans votre accord, et vos équipes voient ce qui est automatisé et peuvent le corriger.
Je cadre, je construis, je fais tourner
Je reste là après la mise en production. Je surveille les automatisations au quotidien, j’interviens en cas d’incident, et vous recevez un compte rendu écrit : ce qui a tourné, ce qui a été corrigé, ce que je propose ensuite. Pour une PME comme pour une équipe plus grande, un seul interlocuteur, de la première question à l’exploitation.
Les agents écrivent, je relis : chaque modification passe une grille de contrôle avant la mise en ligne.
Des cas concrets
Les e-mails entrants classés par un modèle qui apprend
Pour un tour-opérateur. La décision : sous un seuil de confiance, l’e-mail va à un opérateur. Si ça casse : le message qui échoue est mis de côté et noté comme erreur critique. Ce qui se voit : chaque décision du modèle est journalisée et consultable par l’équipe.
Lire le casLa production logicielle par agents
La décision : chaque agent a un rôle borné, et aucun ne déploie. Si ça casse : la relecture et les tests renvoient le code à son auteur. Ce qui se voit : le journal des décisions de chaque agent, et une personne qui valide chaque mise en production.
Lire le casUne seule plateforme pour les sites de mes clients
La décision : une base commune, des sites distincts. Si ça casse : l’erreur reste en amont, entre l’environnement de travail, la pré-production et la production. Ce qui se voit : des sites que les équipes éditent elles-mêmes, avec un aperçu avant publication.
Lire le casLumineth Hub, la preuve visible
Les agents décrits sur cette page tournent dans Lumineth Hub, en bêta sur mes propres sites : file de propositions, garde-fous, suivi des envois et alertes.
Voir Lumineth HubPour les équipes techniques
Sous le capot : des agents IA construits pour la production
Pour un CTO, une DSI ou un ingénieur qui veut savoir comment c’est construit. Les agents de Lumineth Hub suivent une règle fixe : le code calcule, le modèle propose, le code vérifie, une personne décide. Chaque exécution laisse une trace complète : faits envoyés, empreinte du prompt, modèle, jetons, coût et décision.
- Un workflow agentique dont le chemin est fixé par le code : collecte des faits, prompt versionné, appel au modèle, contrôle, file de validation. Le modèle ne fait que l’étape qui demande du jugement.
- Claude, d’Anthropic : Sonnet pour l’analyse, Opus pour le rapport mensuel que vous lisez. Appel par AWS Bedrock depuis Zurich, avec un traitement limité aux régions européennes d’AWS, ou par l’API d’Anthropic, au choix pour chaque site. À Zurich, Bedrock donne aussi accès aux modèles d’OpenAI (GPT), de xAI (Grok) ou de Cohere : je choisis le modèle adapté à chaque tâche, et on en change sans tout refaire.
- Sortie structurée : le modèle répond dans un schéma JSON imposé. Les contraintes que l’API n’accepte pas (longueurs, nombre d’éléments) lui sont redites, puis le code vérifie le schéma complet. Une réponse non conforme ne produit aucune proposition.
- Rien n’est publié sans une décision humaine. Une proposition acceptée est appliquée par les fonctions du Hub, jamais par le modèle, et la décision est inscrite au journal d’audit.
- Chaque proposition passe des garde-fous écrits en code. Chaque preuve citée doit être l’identifiant d’un fait réellement collecté, et tout nombre écrit doit figurer dans les faits : un chiffre inventé bloque la proposition.
- Le ton du site est contrôlé lui aussi : cadratin, superlatifs invérifiables et marqueurs internes bloqués, longueurs du title et de la méta vérifiées, recherche mesurée en tête du title. Chaque site a sa fiche de ton, et ses mots interdits s’ajoutent aux règles communes.
- Dans un rapport, une phrase qui annonce une cause doit citer un fait capable de l’expliquer, sinon le rapport est bloqué.
- Un jeu de référence (golden set) par tâche : 19 cas pour l’agent SEO, dont 11 réponses fautives exprès, pour vérifier que c’est le bon garde-fou qui réagit. Les evals tournent hors ligne dans la suite de tests, puis avec le vrai modèle avant chaque mise en service et chaque changement de prompt ou de modèle.
- Une exécution à la fois par site et par tâche (verrou en base). Une même idée n’est jamais deux fois en attente (clé de dédoublonnage et contrainte d’unicité), ni reproposée dans les 90 jours qui suivent une décision.
- 120 secondes au plus par appel au modèle. Erreur passagère : nouvel essai après 15 minutes, délai doublé à chaque échec, 24 heures au plus (retries with backoff). Erreur définitive ou cinq échecs de suite : arrêt et alerte au tableau de suivi, plus aucun essai à l’aveugle.
- Faits identiques à la dernière analyse : le modèle n’est pas appelé. Jetons et coût sont inscrits à chaque exécution, au tarif public ; un coût inconnu reste affiché comme inconnu.
- Pour les envois, la même rigueur : e-mails enregistrés avant d’être envoyés (outbox, cinq tentatives, échec visible), formulaires relayés avec signature HMAC et identifiant unique, paiements Stripe avec clé d’idempotence et webhooks signés.
- Une base MySQL par site, des migrations versionnées, un journal d’audit que l’interface ne peut pas modifier, sans adresse IP en clair.
- Jetons Google et accès aux boîtes e-mail chiffrés en base (libsodium), jamais renvoyés à l’écran.
- Sauvegarde chaque nuit de la base et des fichiers, et copie hors serveur vers Amazon S3 à Zurich, chiffrée sur le serveur avec une clé publique : la clé privée n’est jamais chez AWS.
- Aucune donnée personnelle n’est envoyée au modèle sans un réglage explicite du site. Une tâche qui en envoie passe seulement par Bedrock en Europe, jamais par l’API d’Anthropic. L’agent SEO n’envoie que des recherches agrégées par Google et des pages publiques.
- Lecture de vos boîtes e-mail par IMAP, en lecture seule : le client IMAP refuse toute commande d’écriture avant qu’elle parte sur le réseau, et vos e-mails restent « non lus » chez votre hébergeur. Connexion TLS, certificat vérifié.
- Classement par des règles que vous modifiez, puis par un modèle avec seuil de confiance. Les cas incertains et les brouillons de réponse attendent votre validation.
- Sur AWS, une chaîne de réception événementielle : e-mail reçu par Amazon SES, déposé dans S3, file SQS avec file d’erreurs (DLQ), fonctions Lambda qui analysent, classent et rattachent au bon dossier.
- Courrier papier, lettres et factures scannées : OCR (Amazon Textract, ou un moteur hébergé en Suisse quand les documents l’exigent), puis le même classement et le même seuil de confiance.
- Je peux entraîner un modèle sur l’historique de vos décisions : classement de texte (TF-IDF et régression logistique quand cela suffit), versionné, réentraîné avec les corrections de vos équipes. Il reste à vous et n’entraîne aucun modèle public.
- Google : connexion OAuth avec les seuls droits utiles (fiche Google, Search Console en lecture seule), API Search Analytics en données définitives, par paquets de 25 000 lignes, sur 16 mois d’historique. « Déconnecter » révoque l’accès chez Google.
- MCP : un client MCP (JSON-RPC 2.0, HTTP streamable, réponses JSON ou SSE) relie le Hub à des outils externes, et un serveur MCP laisse vos assistants IA lire vos données avec vos droits.
- Je connecte votre CRM, votre ERP ou vos outils métier par API REST et webhooks, signés et idempotents.
Questions fréquentes
Qu’est-ce qu’un agent IA ?
Un programme qui prend en charge une tâche répétitive, avec un modèle d’IA pour la partie qui demande du jugement : lire un e-mail, classer une demande, préparer une réponse. Le chemin est fixé par le code, l’agent propose, et une personne de votre équipe décide. Il se branche sur vos outils et tourne en production, surveillé.
Par où commencer ?
Par un cas concret qui coûte du temps chaque semaine. On le cadre ensemble, on mesure, et on étend si ça tient.
Mes équipes vont-elles perdre la main ?
Non. Le modèle apprend des décisions de vos équipes, un humain valide les cas incertains, et chaque correction le réentraîne. Les décisions sont écrites.
Et si le modèle se trompe ?
Sous un seuil de confiance, le cas passe à un humain. Sa correction réentraîne le modèle. Le ratio d’erreurs acceptable est fixé par vous, pas par l’algorithme.
Faut-il un gros projet pour commencer ?
Non. On commence par un processus, en production, mesuré. L’extension vient après.
Comment est construit un agent IA en production ?
Sur un chemin fixé par le code. Le code collecte et calcule les faits, Claude propose dans un schéma JSON imposé, le code vérifie chaque preuve et chaque chiffre, puis une personne de votre équipe accepte ou refuse. Chaque exécution est tracée (prompt, modèle, jetons, coût), et la tâche est rejouée sur un jeu de cas de référence avant toute mise en service.
Quel modèle d’IA utilisez-vous, et où vont les données ?
Claude, d’Anthropic : Sonnet pour l’analyse, Opus pour les textes rédigés. L’appel passe par AWS Bedrock depuis Zurich, avec un traitement limité aux régions européennes d’AWS, ou par l’API d’Anthropic, au choix pour chaque site. À Zurich, Bedrock donne aussi accès aux modèles d’OpenAI (GPT), de xAI (Grok) ou de Cohere : je choisis le modèle adapté à chaque tâche, et on en change sans tout refaire. Une donnée personnelle ne part jamais par l’API d’Anthropic, et seulement si votre site l’autorise. Je peux aussi entraîner un modèle propre sur vos données.
Parlons de votre projet
Dites-moi ce que vous voulez faire avancer ; je reviens vers vous sous 24 heures ouvrées.