Construire un SaaS piloté par des agents : journal de bord et arbitrages

J'ai passé plusieurs mois à concevoir et construire une plateforme SaaS pilotée par des agents IA, de la recherche utilisateur à la mise en production. Cet article rassemble ce que je n'aurais pas compris en restant sur des maquettes — y compris les erreurs.

1. Le coût est une contrainte de design, pas de facturation

Chaque appel modèle a un prix. Chaque donnée enrichie chez un fournisseur tiers aussi. Sur un produit de prospection, cette contrainte n'est pas un détail comptable : c'est la variable qui structure l'expérience.

Elle est remontée directement dans l'interface sous la forme d'une cascade :

• ce qui a déjà été payé se réutilise gratuitement ;
• ce qui peut être déduit d'une information existante est déduit puis vérifié, sans frais ;
• l'enrichissement payant n'intervient qu'en dernier recours, avec son coût affiché avant validation.

Une règle économique est devenue un parcours utilisateur. C'est probablement la décision de design la plus structurante du produit, et elle n'aurait jamais émergé d'un atelier sur les écrans.

Ce que j'en retiens : sur un produit IA, commencez par modéliser l'économie d'une action avant de dessiner l'écran qui la déclenche.

2. La validation explicite n'est pas une friction, c'est le produit

Un agent qui agit sans confirmation gagne quelques secondes et perd la confiance de l'utilisateur. J'ai testé les deux.

La version sans confirmation était objectivement plus rapide. Elle a produit un comportement que je n'attendais pas : les utilisateurs ont commencé à vérifier manuellement après coup ce que l'agent avait fait. Le temps gagné à l'exécution était reperdu en contrôle, avec en prime un sentiment de dépossession.

La confirmation n'est pas une friction résiduelle à supprimer. C'est ce qui rend l'automatisation acceptable. La bonne question n'est pas « comment enlever la validation », c'est « pour quelles actions la validation est-elle superflue » — et la réponse se décide tâche par tâche, selon le coût de l'erreur et sa réversibilité.

3. L'erreur qui m'a coûté trois semaines

J'ai mis de l'IA générative dans un endroit où elle n'avait rien à faire.

Le cas : afficher à l'ouverture de l'application ce que l'utilisateur devait traiter en priorité. Mon premier réflexe a été d'envoyer le contexte à un modèle et de lui demander de rédiger le résumé. Ça marchait. C'était même impressionnant en démonstration.

En usage réel, trois problèmes sont apparus :

• le résumé changeait de formulation d'un jour à l'autre pour des données identiques — impossible pour l'utilisateur de repérer ce qui avait bougé ;
• chaque ouverture coûtait un appel modèle, pour une information que trois requêtes en base produisent gratuitement ;
• le jour où le modèle s'est trompé de chiffre, tout le reste de l'écran est devenu suspect.

La version actuelle ne contient aucune génération : un comptage, des seuils, un texte à trous. Plus rapide, gratuite, stable, et personne ne l'a jamais remise en question.

La règle que j'en tire : l'IA générative sert à traiter le non structuré. Dès que la donnée est structurée, elle est un coût et un risque. Le réflexe « on met un LLM » précède souvent la question « quel est le problème ».

4. Ce qui casse en production n'est jamais le modèle

C'est le cas limite. La donnée absente, le quota atteint, le compte tiers déconnecté, le format inattendu. Le modèle, lui, fonctionne assez bien.

Trois exemples réels :

• un jeton d'authentification expiré côté fournisseur, silencieusement — l'agent continuait de tourner et produisait des résultats vides ;
• une entreprise sans site web, ce qui cassait toute la logique de déduction d'adresses email ;
• un utilisateur qui lançait deux traitements simultanés, ce que rien n'interdisait et que rien n'anticipait.

Aucun de ces trois cas n'était visible en maquette. Tous sont devenus évidents après trois semaines d'usage réel.

Ce que j'en retiens : la qualité d'un produit agentique tient à la qualité de ses chemins de repli, pas à la qualité de son modèle. Le budget de conception devrait être réparti en conséquence.

5. Le tableau de décision comme livrable central

Le document le plus utilisé par l'équipe n'était pas un fichier de design. C'était un tableau : une ligne par action automatisable, quatre colonnes — déclencheur, autonomie, repli, trace.

Rempli en atelier avant la première maquette, il a produit trois effets. Les désaccords sont sortis tôt, quand ils coûtaient une heure au lieu de trois semaines. Les écrans sont devenus presque mécaniques une fois les quatre colonnes arbitrées. Et les cas d'erreur ont été conçus comme du produit plutôt que découverts en recette.

Une maquette décrit ce que le système montre. Ce tableau décrit ce qu'il fait quand personne ne regarde. Sur un produit agentique, la deuxième question compte davantage.

6. La méthode d'atelier qui a remplacé les slides

Le format d'atelier classique produit un consensus qui ne survit pas à la première semaine de développement. Trois heures de discussion, des post-it, un compte-rendu validé par tous. Puis, deux mois plus tard : « ah, mais ce n'est pas ce qu'on avait dit ». Personne n'a menti : chacun a validé sa propre abstraction.

Ce que je fais maintenant, en trois temps :

• 45 minutes de cadrage sur une seule tâche, la plus pénible du quotidien, avec sa donnée réelle. Pas la vision, pas la roadmap.
• 90 minutes d'assemblage devant eux. Sans finition, sans design abouti — un enchaînement qui fonctionne sur leurs données à eux.
• 30 minutes pour le casser. C'est le moment le plus utile de la journée : les objections qui ne sortaient jamais pendant les ateliers papier sortent en cinq minutes face à un écran qui fait quelque chose de faux.

Ce qui sort de la salle n'est pas un compte-rendu, mais un objet plus une liste de raisons précises pour lesquelles il ne convient pas encore. C'est infiniment plus exploitable qu'un consensus.

7. Ce que je referais différemment

Modéliser les états dégradés avant les états nominaux. J'ai fait l'inverse et j'ai payé la dette en fin de projet. Commencer par « que se passe-t-il quand ça échoue » discipline énormément la conception du chemin heureux.

Instrumenter l'usage dès le premier jour. Pendant les premières semaines, je n'avais aucune visibilité sur ce que les utilisateurs faisaient réellement. Les décisions se prenaient à l'intuition. Trois compteurs simples auraient suffi à en éclairer la moitié.

Écrire les prompts comme des composants dès le départ. Ils ont vécu trop longtemps dispersés dans le code, sans versionnement ni revue. Les rassembler et les traiter comme du design a immédiatement amélioré la cohérence du produit.

Ce que ce projet a confirmé

Que la partie difficile d'un produit IA n'est pas l'IA. C'est tout ce qui l'entoure : l'économie de chaque action, la répartition de l'autonomie, les chemins de repli, la trace que l'utilisateur peut relire.

Et que ces décisions-là sont du design, même quand elles ne ressemblent à rien de visuel. Elles se prennent tôt, elles se prennent une fois, et elles déterminent presque tout le reste.