Nous avons construit notre propre assistant IA — parce que nous vendons cette capacité.
Un cabinet qui conseille sur l'IA et les solutions sur mesure devrait pouvoir en montrer une qu'il exploite lui-même. Mira est l'assistant conversationnel de ce site : elle qualifie la situation d'un visiteur et l'oriente vers l'étape la plus utile, en français comme en anglais. Nous l'avons conçue, construite et nous l'exploitons. Voici comment — et ce que cela dit de notre façon de travailler.
Un formulaire ne qualifie personne.
Un visiteur arrive avec une situation, pas avec une demande de prestation. Il ne sait pas s'il lui faut une revue de son SI, un cahier des charges, une conversation sur le financement — ou rien du tout. Un formulaire le force à deviner. Un chatbot générique répondrait en langue de plaquette. Il nous fallait autre chose : un outil qui pose deux ou trois vraies questions et oriente vers quelque chose d'utile — et qui ne survend jamais en notre nom.
Configurer, acheter ou construire — la méthode que nous avons appliquée à nous-mêmes.
C'est l'arbitrage que nous menons pour nos clients dans le Studio de solutions métier ; nous l'avons donc mené sur notre propre besoin. Les plateformes de chatbot toutes faites étaient l'option évidente : rapides, hébergées, sur abonnement. Nous avons choisi de construire, pour des raisons que nous pouvons énoncer clairement.
- Acheter — écarté. Les plateformes sur abonnement facturent à la conversation ou au poste, et la logique de qualification vit dans le produit d'un tiers. Nous louerions la chose même qui décide de la façon dont nous parlons à nos prospects.
- Construire — retenu. Un unique Cloudflare Worker qui appelle directement un modèle de langage. La logique de qualification, les garde-fous et le ton sont les nôtres, dans un fichier que nous maîtrisons, déployé en quelques minutes.
- Le compromis assumé. Pas de tableau de bord éditeur, pas de support externe : l'exploitation est à nous. Pour un système de cette taille, c'est un échange équitable — et exactement l'arbitrage que nous recommanderions à un client au besoin comparable.
Ce qu'il ne dira jamais.
Le plus difficile n'était pas de le faire parler. C'était de le faire s'arrêter. Un assistant qui s'exprime au nom d'un cabinet de conseil peut créer des engagements que le cabinet n'a jamais pris — c'est le vrai risque, et c'est la part que la plupart des projets IA sous-estiment.
- Il ne confirme jamais l'éligibilité à un financement. Il peut nommer des dispositifs susceptibles de s'appliquer, mais l'éligibilité s'évalue au cadrage et la décision appartient au financeur. Il le dit.
- Il ne donne jamais ni prix ni délai. Ces sujets se traitent dans un échange avec une personne.
- Il ne promet jamais ni conformité ni certification. Il prépare et structure ; il ne certifie pas.
- Il ne remplace jamais le jugement d'un consultant — et il le dit au visiteur.
- Hors de son périmètre, il renvoie vers un humain plutôt que d'improviser.
Léger, maîtrisé, respectueux de la vie privée dès la conception.
- Architecture — un unique Cloudflare Worker en périphérie, qui appelle un modèle de langage avec un system prompt que nous maintenons. Aucune plateforme intermédiaire.
- Bilingue — français et anglais, avec des instructions distinctes par langue, pas la traduction de l'une dans l'autre.
- Contrôle des abus — limitation du débit par IP et quota quotidien par adresse, pour que l'usage reste lié à de vraies conversations.
- RGPD dès la conception — les conversations ne sont pas stockées sur nos serveurs. L'e-mail demandé sert au contrôle d'accès et, avec consentement, au suivi. C'est annoncé au visiteur, dans le widget.
- Discipline de coût — mise en cache du prompt et longueur de réponse bornée. Le système tourne sur une infrastructure que nous utilisons déjà.
La capacité est transférable. Le chatbot n'est pas le sujet.
Vous n'avez probablement pas besoin d'un assistant qui qualifie des prospects en conseil. Mais la capacité qui est dessous, c'est celle que nous apportons à votre problème : décider s'il faut construire tout court, concevoir un système qui lit une situation et produit un résultat exploitable, et — surtout — borner ce qu'il a le droit de dire. C'est ce que nous faisons dans le Studio de solutions métier, appliqué à votre processus plutôt qu'au nôtre.
- Nous arbitrons configurer / acheter / adapter avant d'écrire une ligne de code.
- Nous concevons les garde-fous avant les fonctionnalités.
- Nous ne construisons que ce qui pourra être maintenu par celui qui en héritera.
Deux leçons que nous appliquons désormais en mission.
- La dérive de positionnement est réelle. Quand notre propre positionnement a changé, l'assistant a gardé l'ancien vocabulaire un moment — ses instructions étaient maintenues séparément du site. Tout système IA qui parle en votre nom doit voir sa langue révisée à chaque évolution de votre message, sinon il vous contredit en silence.
- Le dernier kilomètre casse les systèmes. Un système qui fonctionne et un système qui atteint ses utilisateurs sont deux choses différentes. Nous traitons désormais l'intégration entre l'interface et le moteur comme une partie de la livraison, pas comme un détail de fin de projet.
Ce que ce cas est — et n'est pas
Ce cas décrit notre propre système, pas une mission client — nous le disons plutôt que de le déguiser. Il ne contient aucun chiffre de performance, parce que nous n'en avons mesuré aucun que nous serions prêts à publier. Ce qu'il documente, ce sont la conception, les décisions et les contraintes — vérifiables : Mira est en ligne sur ce site, et vous pouvez tester les garde-fous vous-même.
Pour aller plus loin
Un problème qui pourrait nécessiter un système comme celui-ci ?
Apportez-nous le problème, pas un cahier des charges. On vous dira honnêtement s'il faut configurer, acheter, automatiser, adapter — ou construire.