Greg | Levolia

Je construis Levolia : des agents IA par métier pour les PME. Ici, je partage les coulisses : démos, choix techniques, ratés et leçons du terrain. Aussi Trip Control et Hiku. Si tu construis ou utilises des agents IA, on a des choses à se raconter.

"Vendre dans ChatGPT" ne veut pas forcément dire encaisser dans ChatGPT. La documentation actuelle de Shopify fait une distinction intéressante. Pour les boutiques éligibles, ChatGPT peut faire découvrir les produits. Mais l'achat se termine sur le checkout de la boutique, ouvert dans le navigateur intégré ou dans un nouvel onglet sur le web. La conversation peut donc commencer ailleurs sans que le marchand abandonne sa caisse, ses moyens de paiement ou ses personnalisations. Je trouve ce modèle plus intéressant que l'image d'une IA qui absorberait tout le commerce. Il sépare deux batailles : être choisi et conclure la vente. Côté découverte, Shopify transmet notamment les titres, descriptions, variantes, prix et disponibilités dans un format structuré. Ce travail sur le catalogue compte autant que la vitrine : un produit doit être compris pour pouvoir être proposé dans une conversation. Côté vente, le marchand garde son parcours de paiement. L'assistant apporte un nouveau point d'entrée ; il ne remplace pas automatiquement toute la boutique. Le périmètre mérite d'être précisé : Shopify exige pour ce canal une boutique qui vend aux États-Unis, même si elle est basée ailleurs. Les produits exclusivement B2B ne sont pas pris en charge. Ce n'est donc pas "tous les commerçants peuvent vendre partout dans ChatGPT". Pour une marque, je vois deux chantiers différents : rendre ses produits compréhensibles par les assistants, puis convertir la visite une fois le client arrivé. Une belle fiche qui n'est jamais proposée ne vend pas. Une recommandation qui mène à un mauvais parcours d'achat non plus.

Ces lunettes transforment en texte des mots que vous ne prononcez pas. C'est la démo de Subvocal (Y Combinator), partagée par David Lieb, cofondateur de Google Photos. On articule en silence. Le système lit les micro-mouvements du visage. Le texte s'écrit en temps réel. Pourquoi ça me parle autant ? Ça fait des mois que je dicte presque tout à l'IA avec @WisprFlow. Parler va plus vite que taper. Et surtout, on pense mieux à voix haute. Mais au bureau, personne n'a envie de parler à son ordinateur devant ses collègues. Le vrai frein à la voix n'a jamais été la techno. C'est le regard des autres. Et il y a un usage qui va bien au-delà de l'open space. Certaines personnes muettes ou privées de voix, après une maladie, une opération ou un accident, peuvent encore articuler. Mais le son ne sort pas. Aujourd'hui, face à quelqu'un qui ne connaît pas la langue des signes, elles écrivent sur un téléphone, tapent sur une tablette ou passent par un tiers. C'est lent. La conversation perd tout son naturel. Imaginez : → la personne articule → les lunettes transcrivent → une voix de synthèse parle pour elle, en temps réel En face, rien à apprendre, rien à installer. On écoute, on répond. Une conversation normale. On est encore au prototype, et rien ne dit que ça marchera pour tout le monde. Mais pour la première fois, une interface pensée pour la productivité pourrait rendre la parole à ceux qui l'ont perdue. Vous voyez d'autres usages auxquels on ne pense pas encore ?

Une case vide n'est pas un zéro. Cela paraît évident dans un tableau. Pourtant, la différence peut disparaître quand on demande à une IA de préparer une synthèse. Un point de vente n'a transmis aucun chiffre. Le rapport indique qu'il n'a réalisé aucune vente. Un fournisseur n'a pas confirmé de retard. Le suivi annonce que toutes ses livraisons sont à l'heure. Dans les deux cas, le document remplace une information manquante par une conclusion rassurante ou inquiétante. Pour un suivi d'activité en PME, je voudrais voir ce qui a été reçu, ce qui manque et la période réellement couverte. Un total sur huit établissements ne devrait pas être présenté comme celui des dix établissements du réseau. L'IA pourrait aider à repérer ces trous et préparer les demandes de précision. Si une estimation est nécessaire, elle devrait rester identifiable, avec son hypothèse, au lieu de se mélanger aux chiffres constatés. Je garderais aussi la possibilité de publier un bilan provisoire. Attendre toutes les réponses n'est pas toujours possible ; prétendre les avoir reçues n'est pas une solution. Le lecteur doit pouvoir distinguer "aucune vente", "chiffre non transmis" et "activité non concernée". Ces situations peuvent mener à des décisions très différentes. Un rapport utile ne montre pas seulement les chiffres disponibles. Il permet de comprendre ce qu'ils ne couvrent pas encore.

Un assistant interne peut citer sa source et donner quand même une consigne périmée. Le lien fonctionne. Le document existe. La réponse reprend fidèlement ce qui est écrit. Mais la procédure a changé depuis. Pour une PME qui veut interroger ses documents avec l'IA, je ne regarderais donc pas seulement ce qu'on ajoute à la base. Je regarderais aussi ce qu'on doit en retirer ou rendre clairement obsolète. Une ancienne grille tarifaire, une procédure remplacée ou un modèle de contrat abandonné peuvent rester utiles comme archives. Cela ne veut pas dire qu'ils doivent servir à répondre à une question sur le travail d'aujourd'hui. Je donnerais à chaque document important un responsable et un statut compréhensible : applicable, à revoir ou conservé pour l'historique. Quand une nouvelle version arrive, l'ancienne ne devrait pas rester une autre réponse possible sans explication. L'IA pourrait signaler les documents qui semblent se contredire. La personne responsable devrait confirmer lequel s'applique, plutôt que laisser l'outil choisir selon la formulation la plus convaincante. Et si ce choix n'est pas encore fait, je préférerais une réponse qui montre le désaccord et demande une vérification. Une base documentaire utile ne grandit pas seulement par accumulation. Elle demande aussi qu'on sache ce qui ne doit plus guider le travail.

Si l'IA fait le travail du débutant, comment celui-ci apprend-il à vérifier le résultat ? Dans une petite entreprise fictive, une nouvelle recrue reçoit un devis déjà préparé par un agent. On lui demande de le relire avant envoi. Mais elle n'a pas encore appris à repérer une quantité inhabituelle, une prestation oubliée ou une condition mal appliquée. Lui confier la validation ne lui donne pas automatiquement les moyens de la faire. Je construirais donc un parcours d'apprentissage autour des points à contrôler. Sur quelques dossiers accompagnés, la personne explique ce qu'elle vérifie et pourquoi. Un collègue expérimenté montre ensuite ce qui lui aurait fait reprendre le devis ou poser une question au client. L'IA pourrait aider à préparer des exercices à partir de cas autorisés, avec des erreurs connues et sans données client inutiles. Mais le corrigé devrait être revu par quelqu'un qui connaît le travail. Je garderais aussi des étapes où la recrue formule sa propre réponse avant de voir la proposition de l'outil. Pas pour lui faire refaire tout le travail à la main, mais pour voir ce qu'elle comprend et ce qui mérite encore une explication. Le temps gagné sur la préparation pourrait ainsi laisser une place à cet accompagnement. Ce n'est pas garanti : il faut le prévoir. Dans un travail assisté par l'IA, apprendre le métier peut aussi vouloir dire apprendre à ne pas accepter trop vite une réponse bien présentée.

Le premier contact après une vente ne devrait pas ressembler à une collecte de pièces sans fin. Une entreprise peut avoir besoin de nombreuses informations pour démarrer une prestation. Le client, lui, ne sait pas forcément lesquelles sont urgentes, où les trouver ni pourquoi on les lui demande. Avant d'ajouter un agent IA qui relance automatiquement les documents manquants, je regarderais l'ordre des demandes. Qu'est-ce qui permet de commencer ? Qu'est-ce qui sera utile plus tard ? Qu'est-ce que l'entreprise possède déjà dans le devis accepté ou les échanges précédents ? L'IA pourrait préparer une demande adaptée au dossier : les éléments déjà reçus, les quelques informations nécessaires à la prochaine étape et une explication simple pour chacune. Le responsable vérifierait ensuite que la liste correspond bien à la prestation vendue. Ce serait différent d'un long formulaire identique pour tous. Si le client ne répond pas, répéter la même demande plus souvent n'aidera pas forcément. Il peut manquer un document, ne pas comprendre le terme utilisé ou attendre une décision de quelqu'un d'autre. Le parcours doit lui permettre de le dire. Je regarderais alors le délai avant le premier travail utile, mais aussi les informations redemandées et les échanges nécessaires pour clarifier la demande. L'objectif ne serait pas d'obtenir toutes les cases remplies le plus vite possible. Ce serait de permettre au client et à l'équipe de commencer avec ce dont ils ont réellement besoin.

L'agent IA généraliste fait les gros titres. Mais l'argent sérieux part de plus en plus vers les agents spécialisés dans un métier. Quelques exemples récents : → Hyphenate lève 45 M$ en série A, menée par Nexus Venture Partners. Ses agents prennent en charge la comptabilité générale, la trésorerie, l'order-to-cash, le procure-to-pay et le reporting financier. Ils se branchent sur l'ERP et les systèmes bancaires existants, sans tout remplacer. → @salesforce lance des agents « job-ready », préconfigurés pour un rôle précis, comme Piper, un agent SDR, plutôt que des agents à construire de zéro. → @MistralAI lève 3 Md€ et dépasse 21 Md€ de valorisation, avec notamment le Scaleup Europe Fund, soutenu par l'UE. Son pari : travailler avec chaque entreprise pour construire des outils sur mesure, intégrés à son activité. Pourquoi les agents verticaux gagnent du terrain ? Parce qu'un processus métier a ses règles, son vocabulaire et ses contraintes. Un agent qui ne les connaît pas produit du texte plausible. Un agent qui les connaît produit un travail utilisable. C'est particulièrement vrai pour les marchés publics, un des terrains sur lesquels on construit chez @Levolia_ai avec AO Manager. Lire un dossier de consultation, repérer les critères, vérifier les pièces, tenir les délais : c'est là que la spécialisation fait la différence. Et en Europe, il y a une deuxième dimension : la souveraineté. Côté réglementation, l'omnibus numérique de l'AI Act a fixé un calendrier plus clair. Les obligations sur l'IA à haut risque sont reportées au 2 décembre 2027, ou au 2 août 2028 pour l'IA intégrée à des produits. Mais une échéance arrive bien plus vite : le délai de grâce pour les solutions de transparence sur les contenus générés par IA prend fin le 2 décembre 2026. Côté offre, les acteurs européens font de l'hébergement un argument commercial. Les données de Vibe, l'assistant de Mistral, sont hébergées dans l'UE par défaut. Voxtral 3, son SDK pour agents vocaux, tourne sur l'API européenne de Mistral ou sur l'infrastructure du client. Pour un éditeur d'agents B2B en France, je vois trois exigences en 2026 : Maîtriser le métier mieux que le modèle généraliste. Savoir dire où sont les données et si elles servent à entraîner un modèle. Anticiper les échéances de l'AI Act au lieu de les subir. Et vous, dans vos achats d'IA, la souveraineté est-elle un vrai critère de choix, ou un argument qu'on oublie dès que la démo est bonne ?

Tout le monde parle de GEO, l'optimisation pour les moteurs d'IA. Une étude récente devrait calmer un peu le jeu. Marie Haynes a analysé 12 mois de données GA4 sur 100 sites, soit plus de 145 millions de sessions. @sengineland a publié les résultats le 21 octobre. Ce qu'elle a trouvé : → ChatGPT génère seulement 0,62 % du volume de sessions de Google organique. Tous les LLM réunis : 0,73 %. Et c'est 0,73 % du trafic Google, pas du trafic total du site. → Sur les 55 sites qui suivent leurs conversions, les visiteurs venus de ChatGPT convertissent à 13,8 %, contre 3,02 % pour ceux de Google organique. → Mais en volume, Google organique apporte 27 fois plus de conversions que tous les LLM réunis. → Selon elle, la croissance des visites venues de ChatGPT a cessé d'être exponentielle en août 2025, puis a reculé. Sa conclusion est tranchée : le GEO serait « une distraction ». Je ne suis pas complètement d'accord, et Search Engine Land non plus. Ces chiffres disent où en est le trafic aujourd'hui, pas ce que pèsera la visibilité dans les IA demain. L'étude a aussi ses limites : elle ne précise ni les secteurs, ni la définition des conversions. Ce que j'en retiens, pour le SEO comme pour l'agent SEO qu'on construit chez @Levolia_ai : Google reste la source n°1 de trafic et de business. L'abandonner pour courir après ChatGPT serait une erreur. Le trafic venu des IA est petit mais très qualifié. Il faut le mesurer à part, pas le noyer dans le reste. Les éditeurs commencent à le mesurer : dans sa nouvelle Marketing Studio, HubSpot affiche un score de visibilité AEO (« answer engine optimization »). HubSpot se présente aussi comme le premier CRM intégré aux publicités ChatGPT. Le bon réflexe n'est donc pas « SEO ou GEO ». C'est un seul pilotage, qui regarde les deux avec des objectifs différents : du volume côté Google, de la qualité côté IA. Un agent SEO utile en 2026 ne doit pas seulement produire du contenu. Il doit dire où l'effort rapporte vraiment. Et vous, mesurez-vous déjà séparément le trafic qui vient des assistants IA ? Qu'est-ce que ça donne ?

Question simple : combien d'agents IA tournent aujourd'hui dans votre entreprise, et qui les a autorisés ? Si vous n'avez pas la réponse, vous n'êtes pas seul. Et en octobre, trois géants ont lancé des produits pour régler exactement ce problème. → @ServiceNow lance AI Passport, un justificatif signé que l'agent consulte pendant qu'il travaille pour vérifier ce qu'il a le droit de faire. Ça vaut aussi pour les serveurs MCP, qui relient les agents aux outils. Tant que l'agent reste dans son périmètre, il agit librement. S'il en sort, il peut être redirigé, restreint, ou arrêté net grâce à un « kill switch ». → @IBM rend disponible Agent Identity. L'idée : traiter chaque agent comme une identité à part entière, avec un inventaire central, un propriétaire désigné, un niveau de risque, les outils qu'il a le droit d'utiliser et un cycle de vie. → @Google annonce Agent Compute Engine, un environnement d'exécution isolé matériellement pour les agents, en préversion dans les prochains mois. Il étend aussi la gouvernance de ses agents à ceux qui tournent ailleurs que chez lui. Le point commun : on a géré pendant des années les accès des humains et des applications. Les agents sont une troisième catégorie, et elle n'entre dans aucune des deux cases. Un agent n'est pas un utilisateur : il ne se fatigue pas et peut faire des milliers d'actions par heure. Ce n'est pas non plus une application classique : il décide lui-même de la suite de ses actions. Chez @Levolia_ai, quand on construit un agent pour un client, la question des permissions passe avant celle des fonctionnalités. Concrètement : - L'agent a le minimum d'accès nécessaire, pas un compte administrateur « pour aller plus vite ». - Chaque action est journalisée et rattachée à une personne qui l'a autorisée. - Il y a un bouton stop, et quelqu'un sait qui a le droit d'appuyer dessus. @AnthropicAI va dans le même sens pour Claude Enterprise. Chaque session de travail autonome tourne dans sa propre machine virtuelle isolée, avec l'accès réseau sortant coupé par défaut et les identifiants des connecteurs gardés hors de la session. La vitesse d'un agent est son atout. Sans garde-fous, c'est aussi son plus gros risque. Et vous, si un de vos agents IA faisait une erreur demain, sauriez-vous retrouver qui l'a autorisé, et à faire quoi ?

"Trop cher" dans un CRM, ça peut vouloir dire plusieurs choses. Le budget était insuffisant. L'offre a été comparée à une prestation moins étendue. Le client n'a pas compris ce qui était inclus. Ou le commercial a choisi cette catégorie faute de retour plus précis. Pour une PME qui veut analyser ses affaires perdues avec l'IA, je commencerais par cette ambiguïté. Prenons un cas fictif : plusieurs devis sont classés comme perdus pour une raison de prix. Demander à l'IA de recommander une baisse des tarifs à partir de cette colonne serait aller trop vite. Je lui ferais plutôt rapprocher, pour chaque affaire, la catégorie du CRM et les éléments disponibles : compte rendu du commercial, email du client, périmètre proposé. Puis séparer ce que le client a dit de ce qui a été déduit. Un silence après l'envoi du devis n'est pas une objection de prix. Une remise demandée ne prouve pas non plus qu'elle aurait suffi à obtenir la commande. Le premier résultat utile pourrait être une liste de dossiers sur lesquels il manque une information, accompagnée de questions à poser lors du prochain échange. Pas un graphique très propre qui donne une certitude de plus à une saisie incertaine. L'IA peut aider à relire un historique commercial. Elle ne peut pas retrouver à elle seule les raisons que personne n'a recueillies. Avant de changer une offre, je voudrais distinguer les objections exprimées, les hypothèses du commercial et les affaires dont on ne connaît simplement pas la fin.

Un agent IA qui accélère une prestation ne dit pas encore comment la vendre. Prenons une petite société de services fictive qui prépare chaque mois un rapport pour ses clients. Elle facture aujourd'hui le temps passé à rassembler les données, les vérifier et rédiger le document. Si un agent réduit le temps de préparation, plusieurs offres deviennent possibles. Garder une facturation au temps. Proposer un forfait pour un rapport défini. Ou inclure le rapport dans un accompagnement où le client paie aussi pour discuter des décisions à prendre. Ce ne sont pas les mêmes engagements. Pour un forfait, je préciserais ce qui est compris : les sources utilisées, la fréquence, les corrections incluses et les demandes qui sortent du cadre. Un rapport produit rapidement peut coûter cher si chaque livraison déclenche plusieurs allers-retours non prévus. Je regarderais donc le temps de préparation, mais aussi celui passé à récupérer les données manquantes, répondre au client et reprendre le travail. C'est sur l'ensemble de la prestation que le prix doit tenir. L'IA peut aider à revoir l'offre. Elle ne rend pas automatiquement le forfait plus rentable, et elle n'oblige pas non plus à vendre moins cher. Avant de changer le tarif, je voudrais savoir ce que le client achète : un document, une disponibilité, ou une aide pour décider. Le même rapport peut avoir une place différente dans chacune de ces offres.

Le logiciel B2B a été vendu au siège pendant 20 ans. Avec les agents IA, ce modèle commence à se fissurer. Deux annonces récentes le montrent bien. → @HubSpot a ouvert son Prospecting Agent à tous les forfaits payants, Starter compris. Il est facturé 1 $ par lead recommandé. Son slogan : « Pay when work gets done. » → @hone vient de lever 60 M$ en seed, valorisée 285 M$, avec Benchmark et Index Ventures. Son produit, les « Engines », ce sont des systèmes autonomes qui prennent la responsabilité d'un résultat business sur la durée : croissance du revenu, conversion, réduction des coûts, risque opérationnel. Le message est clair : on ne vend plus un outil, on vend du travail fait. Mais ce modèle a un revers qu'il faut regarder en face. Chez HubSpot, chaque lead recommandé consomme 100 crédits. Le forfait Starter en inclut 500 par mois, sans report. Ça fait 5 leads avant de payer en plus. Quand on paie au résultat, il faut savoir précisément ce qu'on appelle un résultat. Côté entreprise, Gartner pointe le même problème. Les coûts de l'IA sont « probabilistes », déterminés à l'exécution, contrairement aux coûts classiques du SaaS. 51 % des DSI s'attendent à ce que l'IA augmente le coût total de leurs solutions. Chez @Levolia_ai, on construit des agents IA B2B, et je pense que la facturation au résultat est la bonne direction. À trois conditions : 1.Le résultat doit être défini avec le client, pas par le fournisseur. Un « lead recommandé » n'est pas un « rendez-vous obtenu ». 2. Il faut un plafond de dépense clair. Les grands acteurs l'ont compris : Google met désormais en avant des plafonds de dépense en temps réel pour ses agents. 3. L'unité facturée doit être assez proche de la valeur réelle pour que le client puisse la défendre devant son directeur financier. Pour un agent qui prépare des réponses aux appels d'offres, par exemple, le bon indicateur n'est pas le nombre de pages générées. C'est le dossier complet, prêt à valider, dans les délais. Le prix au siège récompensait l'adoption. Le prix au résultat récompense la performance. C'est plus exigeant pour nous, éditeurs, et c'est tant mieux. Et vous, vous préféreriez payer votre agent IA au siège, à l'usage ou au résultat ?

13 %. C'est la part des DSI qui disent avoir tiré une valeur « significative ou transformationnelle » de l'IA, selon Gartner, qui a interrogé 2 002 DSI cette année. Pendant ce temps, l'argent coule à flots dans les agents IA :
→ Mistral lève 3 Md€ et dépasse 21 Md€ de valorisation
→ Hone lève 60 M$ en seed pour des agents qui portent des résultats business sur plusieurs mois
→ Google, ServiceNow et IBM lancent tous, en octobre, des outils pour gouverner les agents en entreprise Alors, bulle ou pas ? Je pense que la question est mal posée. Le chiffre le plus intéressant de l'étude Gartner n'est pas ce 13 %. C'est celui-là : seuls 17 % des DSI ont des critères pour abandonner un projet IA déjà en production. Et ceux qui en ont ont 2,6 fois plus de chances de faire partie des organisations les plus performantes. Autrement dit, les entreprises qui réussissent avec l'IA ne sont pas celles qui lancent le plus de projets. Ce sont celles qui savent les arrêter. Gartner le résume en une phrase : « Volume is not value. » Dans une grande organisation, lancer un pilote est facile. L'arrêter est politiquement compliqué. Résultat : des dizaines de POC qui vivotent, que personne n'ose couper. Chez @Levolia_ai, on construit des agents IA B2B, et j'en tire une règle simple. Chaque agent doit avoir, dès le premier jour : - Un KPI business écrit noir sur blanc (temps gagné, taux de réponse, deals avancés) - Une règle d'arrêt : si le KPI n'est pas atteint à telle date, on coupe - Des permissions limitées et un journal de chaque action Ce n'est pas un hasard si ServiceNow vient de lancer un « kill switch » pour agents. La maturité, c'est aussi savoir appuyer sur stop. Une autre donnée Gartner devrait faire réfléchir : seuls 4 % des DSI ont un plan pour redéfinir les rôles dans une équipe mixte humains-agents. On achète des agents, mais on ne repense pas le travail autour. Et vous, dans votre entreprise, qui a le pouvoir d'arrêter un projet IA qui ne marche pas ?

En septembre dernier, @Salesforce et @HubSpot ont lancé leurs agents commerciaux à quelques jours d'écart. Et ils disent exactement la même chose : l'agent ne vaut rien sans ton CRM. Ce qui a été annoncé : → Salesforce sort des agents « prêts à l'emploi ». Piper est un SDR IA qui qualifie les leads entrants et réserve des rendez-vous en temps réel. Les agents « long-horizon », eux, poursuivent un objectif pendant des semaines, du type « relance mes deals à risque ». → HubSpot sort un Prospecting Agent qui surveille plus de 40 signaux d'achat et rédige les messages de prospection. Il propose aussi un CRM qui se met à jour tout seul à partir des appels, mails et réunions. → Le prix change de logique : chez HubSpot, l'agent de prospection est facturé 1 $ par lead recommandé. On paie le travail fait, plus le siège. J'ai passé 20 ans dans le digital et je n'ai jamais vu un outil commercial échouer à cause de sa technologie. Les échecs venaient presque toujours de la donnée : fiches incomplètes, historique éparpillé, process que personne ne suit vraiment. Les agents ne règlent pas ce problème. Ils le rendent visible, et plus vite. Un humain compense un CRM bancal avec sa mémoire et son réseau. Un agent, non : il agit sur ce qu'il voit. Si la donnée est fausse, il relance le mauvais contact, au mauvais moment, avec le mauvais message. Et il le fait à grande échelle. D'ailleurs, ce n'est pas un hasard si HubSpot appelle son nouveau socle « Growth Context ». Salesforce, de son côté, rend son CRM accessible depuis @claudeai et @SlackHQ. La bataille ne se joue plus sur le modèle d'IA mais sur le contexte. Chez @Levolia_ai, on construit des agents IA pour les entreprises, et c'est notre point de départ à chaque projet. Avant de parler d'agent, on regarde trois choses : La donnée est-elle fiable là où l'agent va agir ? Quel résultat précis doit-il produire, et comment le mesure-t-on ? Où l'humain garde-t-il la main pour valider ? Le reste, c'est de l'intégration. Les grands acteurs viennent de valider le marché. La vraie question pour une équipe commerciale en 2027 ne sera pas « quel agent acheter ? » mais « est-ce que mon CRM mérite un agent ? ». Et vous, si vous branchiez un agent sur votre CRM demain, vous lui feriez confiance ?

Je ne mettrais pas une fenêtre de chat devant toutes les tâches d'une PME. Pour décrire une demande inhabituelle, expliquer un problème ou explorer plusieurs pistes, la conversation peut être très pratique. On peut préciser sa pensée au fil de l'échange, sans connaître le nom exact d'une fonction. Mais pour saisir chaque matin les mêmes informations, comparer trois offres ou modifier une date, je regarderais aussi ce qu'un écran simple permet de faire. Un champ montre ce qu'il faut renseigner. Une liste évite de retaper une catégorie. Un tableau permet de voir plusieurs options en même temps. Si l'utilisateur doit réexpliquer à chaque fois comment il veut travailler, la souplesse du chat devient un effort répété. Je pourrais très bien imaginer un outil où l'on décrit sa demande en langage courant au départ, puis où l'on travaille dans une vue adaptée : planning, dossier, liste de pièces ou tableau de comparaison. Et où la conversation reste disponible quand le besoin sort de ce cadre. Pour moi, ajouter de l'IA ne devrait pas obliger les gens à devenir meilleurs en rédaction de consignes. Le produit doit aussi retenir la forme habituelle du travail, avec des choix visibles et faciles à modifier. Parfois, le meilleur usage de l'IA dans une application sera celui qui évite d'avoir à lui parler longtemps.

Une heure gagnée avec l'IA ne devient pas automatiquement une heure facturée. Prenons un bureau d'études fictif. Un agent aide à préparer les réponses aux demandes entrantes. L'équipe passe moins de temps à rassembler les pièces et à rédiger les premiers éléments. Ce temps libéré peut servir à répondre plus vite, à approfondir les dossiers ou à absorber une période chargée. C'est déjà utile. Mais s'il manque des demandes qualifiées, cela ne suffit pas à créer du chiffre d'affaires. À l'inverse, si des dossiers étaient refusés faute de capacité, le même gain de temps peut permettre d'en accepter davantage. À condition que le travail suivant puisse suivre : chiffrage, production, livraison. Je séparerais donc deux choses dans un projet IA : le temps que la tâche cesse de consommer et ce que l'entreprise pourra réellement faire de ce temps. Réduire une dépense, éviter une embauche supplémentaire, mieux servir les clients ou développer les ventes ne se mesure pas de la même façon. Et le choix change le projet qu'on devrait lancer en premier. Un outil peut faire gagner du temps sans créer de capacité vendable. Ce n'est pas un échec. Il faut simplement éviter de présenter les deux comme le même résultat.

Avant de demander à un agent IA de produire un rapport, je demanderais ce que quelqu'un va faire avec. Prenons une réunion commerciale fictive. L'agent peut en tirer un compte rendu agréable à lire. Mais la personne qui reprend le dossier attend peut-être autre chose : les engagements à confirmer, le nom du responsable de chaque suite et les points encore sans réponse. Un texte complet peut donc être un mauvais livrable pour la tâche suivante. Je partirais du geste attendu après la lecture. Mettre à jour une fiche client ? Préparer un devis ? Appeler quelqu'un ? Décider de ne rien faire ? Puis je construirais le résultat autour de ce geste, sans faire disparaître les incertitudes pour remplir toutes les cases. Si une date n'a pas été décidée, je préférerais voir "date à confirmer" plutôt qu'une échéance déduite par l'outil. Si personne n'a accepté une action, je ne transformerais pas une suggestion en tâche attribuée. Le test serait simple : donner la sortie à la personne qui doit s'en servir et regarder si elle peut poursuivre sans réécouter toute la réunion. Pas besoin de fabriquer un tableau pour chaque échange. Parfois, quelques lignes suffisent. Mais le format devrait venir du travail à faire après, pas seulement de ce que l'agent sait bien générer.

Le jour où la personne qui a installé l'agent IA est absente, qui sait encore s'en servir ? Pour un premier essai en PME, je prévoirais une passation très ordinaire : un collègue reprend la tâche sans être guidé à chaque clic. Il doit pouvoir trouver la bonne version, savoir quelles données fournir, reconnaître un résultat incomplet et demander de l'aide au bon endroit. Pas forcément comprendre toute la technique. Je lui donnerais la consigne habituelle, puis je noterais les endroits où il hésite. Une explication orale indispensable devient un élément à documenter. Un accès personnel nécessaire devient un point à régler. Une erreur qu'il ne peut pas reconnaître devient un cas à montrer. Ce test peut aussi révéler qu'on a trop compliqué le parcours. Si cinq pages de mode d'emploi sont nécessaires pour lancer une tâche simple, ajouter une sixième page n'est peut-être pas la meilleure réponse. Je garderais surtout un chemin pour continuer sans l'agent quand il ne fonctionne pas, avec les documents et les décisions déjà récupérables. L'automatisation peut être utile même si une seule personne la maîtrise au départ. Mais avant d'en faire une habitude d'équipe, je voudrais vérifier que le travail ne dépend pas discrètement de sa présence.

Avant de donner un budget mensuel à un agent IA, je lui donnerais une règle pour s'arrêter sur une seule tâche. Imaginons un agent chargé de comparer quelques offres fournisseurs. Une recherche ne donne rien, il change de requête. Une page ne répond pas, il essaie une autre source. Un document manque, il poursuit ailleurs. Chaque tentative peut avoir une raison. Leur accumulation peut pourtant coûter plus cher que le résultat attendu, en argent ou en temps d'attente. Je ne voudrais pas seulement savoir combien la tâche a coûté une fois terminée. Je voudrais décider ce qu'elle peut dépenser avant de devoir demander une décision. Cela peut prendre plusieurs formes : un nombre limité de sources à consulter, une durée maximale, un plafond de coût ou une liste de documents au-delà de laquelle on ne cherche plus automatiquement. À la limite, je demanderais un résultat partiel lisible : ce qui a été trouvé, ce qui manque et pourquoi la tâche s'est arrêtée. Pas un document qui masque ses trous pour donner l'impression d'être terminé. On pourrait alors choisir de continuer, de réduire le périmètre ou de reprendre à la main. Et je testerais ces arrêts sur les dossiers difficiles, pas seulement sur ceux qui se terminent vite. Un agent qui s'arrête avec un résultat incomplet mais explicite peut être plus utile qu'un agent qui continue sans qu'on sache ce que la prochaine tentative apportera.

Quand quelqu'un corrige un agent IA, où va la correction ? Imaginons une PME qui utilise un agent pour préparer des fiches produits. Une collègue repère une unité erronée, la corrige dans le document final et passe à la suite. Le client reçoit la bonne fiche. Le dossier est terminé. Pourtant, rien ne dit que le prochain document évitera la même erreur. La correction peut être restée dans un fichier que l'agent ne relira jamais. Elle peut aussi avoir été faite sans que son origine soit claire : mauvaise donnée de départ, règle mal comprise ou problème de présentation. Avant de chercher à rendre l'agent plus autonome, je regarderais ce parcours très simple : repérer une erreur, la corriger, puis décider ce qui doit changer pour la suite. Toutes les corrections ne méritent pas une nouvelle règle. Une exception pour un client ne doit pas devenir le comportement par défaut pour tous les autres. Je voudrais donc pouvoir distinguer ce qui concerne seulement le dossier en cours, ce qui révèle une donnée à rectifier et ce qui justifie de modifier le fonctionnement de l'outil. Et je garderais une personne responsable de cette décision, avec quelques anciens cas à rejouer après le changement. Un bouton "corrigé" peut fermer un dossier. Il ne suffit pas à montrer que le problème ne reviendra pas.