Oui, un agent IA peut tourner en production en quatre semaines dans un SaaS déjà en service, à condition que le périmètre exclu soit écrit avant la première ligne de code. Chez SuperHote, logiciel de gestion locative utilisé par plus de 100 000 hôtes, le copilote a été livré en 42 jours-homme entre le 8 et le 31 décembre 2025, puis transformé en quatre agents spécialisés en 12 jours ouvrés de janvier. Voici le déroulé semaine par semaine, avec ce qui a cassé en route.
Un point de cadrage d'abord. Les quatre semaines couvrent le pilote, un copilote greffé dans une stack Laravel et React et ouvert à 50 utilisateurs réels. Les quatre agents nommés (Chris, Vaness, Chacha et Sam) sont arrivés dans un second sprint, sur le même socle. Sans décembre, janvier n'aurait pas tenu douze jours.
Semaine 1 : pourquoi le cadrage et les accès décident de tout ?
La première semaine ne produit pas d'agent, elle produit un contrat de périmètre et des accès qui fonctionnent. Cinq critères de succès chiffrés ont été signés avant le lancement, dont un temps d'affichage du premier caractère sous 3 secondes et un taux de réponses pertinentes d'au moins 70 % sur les questions couvertes par la base de connaissances. JUWA s'est engagée sur une pénalité de 10 % en cas de non-atteinte.
Le choix structurant a été pris le premier jour : le copilote ne serait pas un service posé à côté de la plateforme, mais un composant de la plateforme, écrit en Laravel côté serveur, en React côté interface, avec le raisonnement sur AWS Bedrock. Ce choix coûte la première semaine et fait gagner les trois suivantes, parce que l'agent hérite de l'authentification JWT, des journaux et des routes métier en place.
Ce qui a bloqué : les accès. Préproduction, identifiants Bedrock avec les bons quotas, lecture des tables de réservation, transcriptions des vidéos de formation à vectoriser. Chaque élément manquant coûte une demi-journée à un développeur qui attend. D'où un référent back-end et un référent front-end nommés, avec une réponse sous 24 heures écrite dans la proposition. C'est la clause qu'on négocie le plus mal, et celle qui a sauvé le calendrier.
Semaine 2 : un premier agent en bac à sable, avec quel jeu de tests ?
En deuxième semaine, l'orchestrateur tourne en bac à sable sur quelques dizaines de questions réelles, tirées des tickets support et des messages voyageurs, avec la réponse attendue écrite par un référent métier. Sans lui, on ne sait pas si un changement de prompt améliore ou dégrade le système.
La récupération de contexte a été rendue hybride dès cette semaine. Recherche vectorielle sur deux bases de connaissances (le centre d'aide et les transcriptions de formation, découpées par défaut en morceaux d'environ 300 jetons selon la documentation Amazon Bedrock), et requêtes structurées sur la base SuperHote pour tout ce qui concerne un séjour précis. Un agent qui ne fait que du vectoriel répond juste sur les règles générales et se trompe sur la réservation en cours, ce que produisait l'ancien assistant.
Ce qui n'a pas marché du premier coup : les cas limites. Une réservation annulée puis recréée, un voyageur qui écrit en portugais, une question sur un logement que l'hôte ne gère plus. Chaque cas a demandé une règle dans le prompt ou un garde-fou côté API, et la liste s'est allongée toute la semaine.
Semaine 3 : comment intégrer l'agent au produit sans casser la stack ?
La troisième semaine est celle du streaming et de la validation humaine, ce qui sépare une démo d'un produit. Le streaming d'abord. Avec le SDK Bedrock utilisé tel quel, le premier caractère mettait plus de trente secondes à s'afficher. On a abandonné le SDK pour appeler l'API en HTTP direct, puis écrit un module qui convertit le flux en événements SSE, parce que PHP ne diffuse pas nativement une réponse au fil de l'eau. Le texte s'écrit alors à l'écran pendant que le modèle raisonne encore, et le critère des 3 secondes devient tenable.
La validation humaine ensuite. Bedrock ne gère pas nativement la reprise en main par un humain ni l'appel de composants d'interface. Il a fallu la construire, avec des groupes d'actions, des garde-fous et une fonction de rendu des composants front. Le seuil de confiance se règle par utilisateur : un gestionnaire qui suit trente annonces et un autre qui en suit trois cents ne veulent pas le même niveau d'autonomie. Sous le seuil, l'agent propose et l'hôte valide ; au-dessus, l'action part seule et reste tracée.
Gartner prévoyait en juin 2025 que plus de 40 % des projets d'agents IA seraient abandonnés d'ici fin 2027, en citant les coûts qui dérapent, une valeur métier floue et des contrôles de risque insuffisants. Les deux derniers motifs se traitent en semaine 3, pas après la mise en ligne.
Résumé de la vidéo : les équipes AWS montrent, sur un exemple de support client, comment passer un agent Bedrock du prototype à la production avec l'exécution, les outils, la mémoire, l'identité et l'observabilité. Le lecteur y retrouve les briques que le projet SuperHote a dû construire à la main fin 2025, validation humaine et journalisation en tête.
Semaine 4 : que teste-t-on à la recette avant de basculer ?
La recette a porté sur les cinq critères signés, rien d'autre. Le 31 décembre, le copilote tournait devant 50 utilisateurs réels, avec l'API Laravel, le module React, le streaming et deux visioconférences de passation enregistrées. Le détail est dans le cas client du copilote SuperHote.
On a ouvert à 50 utilisateurs, pas à 100 000, et gardé l'ancien assistant en repli. Les cibles de dimensionnement données par le fondateur, 30 000 logements et plus de 2 millions d'interactions par mois, dont 95 % traitées sans intervention humaine et le reste transféré sous seuil de confiance, ont servi à choisir l'architecture. Elles n'étaient pas atteintes au moment du projet.
Un point d'honnêteté sur la latence : les 3 secondes s'appliquent au copilote de l'hôte, hors exécution des actions métier. Une demande qui enchaîne plusieurs appels de fonction prend nettement plus, et c'est écrit comme risque dans le rapport de fin de mission plutôt que caché derrière une moyenne.
Le calendrier en un tableau : livrable, décision, risque
| Semaine | Livrable | Décision qui a fait gagner du temps | Risque rencontré |
|---|---|---|---|
| 1 (8 au 12 décembre) | Cinq critères signés, accès ouverts, architecture arrêtée | Copilote intégré dans la stack Laravel et React, pas en service parallèle | Accès et quotas Bedrock livrés en retard |
| 2 (15 au 19 décembre) | Orchestrateur en bac à sable, jeu de tests métier | Récupération hybride, vectoriel plus requêtes structurées | Cas limites non prévus (annulations, langues, logements sortis) |
| 3 (22 au 26 décembre) | Streaming SSE, validation humaine, module React | Abandon du SDK Bedrock pour l'API HTTP directe | Premier caractère à plus de 30 secondes avant correction |
| 4 (29 au 31 décembre) | Recette sur cinq critères, pilote à 50 utilisateurs, passation | Ouverture progressive, ancien assistant conservé en repli | Latence des enchaînements d'actions, documentée comme risque |
| Sprint de janvier (12 jours ouvrés) | Quatre agents paramétrés, chat en panneau superposé sur le web, application mobile | Périmètre exclu écrit noir sur blanc (pas de recette complète ni d'audit de sécurité) | Démonstration commerciale datée au 31 janvier |
Le sprint de janvier a tenu en douze jours ouvrés avec trois profils à plein temps : quatre agents, chacun avec ses instructions système stockées en base et sa documentation raccrochée à l'identifiant de l'hôte. Le récit complet est dans le cas client des quatre agents SuperHote. Ces agents sont aujourd'hui vendus dans le produit, ce qui reste rare. D'après l'enquête State of AI 2026 de McKinsey (1 719 répondants, mai et juin 2026), environ 20 % des organisations disent avoir atteint le déploiement à l'échelle avec des agents IA.
Qu'est-ce qu'on referait autrement ?
Trois choses, et aucune ne concerne le modèle. La première : tester le streaming en semaine 1, pas en semaine 3. Un test de dix minutes le premier jour aurait montré les trente secondes du SDK. La deuxième : bâtir le jeu de tests métier avant le lancement, avec le client, plutôt que de le remplir en même temps qu'on développe. La troisième : filtrer les réponses d'API dès le départ. Le filtrage dans les fonctions Lambda, appliqué en janvier, a ramené l'entrée d'environ 30 000 à 1 500 jetons par requête. Fait en décembre, il aurait allégé la facture d'inférence dès le pilote.
Ce qu'on ne changerait pas : le périmètre borné. Pas de recette exhaustive ni d'audit de sécurité dans le sprint de janvier, et ces exclusions écrites dans la proposition. Un sprint de douze jours qui prétend tout couvrir ne livre rien. On déconseille aussi de viser l'agent autonome dès la première version. Un agent qui propose et qu'un humain valide entre en production en quatre semaines. Un agent qui agit seul sur des réservations réelles demande une stabilisation que ce calendrier ne contient pas ; sa maintenance est traitée dans cet article sur la maintenance d'un agent IA en entreprise.
Même constat en France. Selon l'étude Bpifrance Le Lab publiée en juin 2025 (1 209 dirigeants interrogés fin 2024), 26 % des PME et ETI utilisent une IA générative et la moitié d'entre elles se contentent d'outils gratuits ou prêts à l'emploi. Un éditeur SaaS qui intègre l'IA dans son produit ne joue pas dans la même catégorie. Des agents métier plus modestes sont décrits dans notre panorama des agents IA métier en PME, et le copilote greffé dans un produit est détaillé dans cet article sur le copilote IA intégré à un produit SaaS.
Comment JUWA mène ce type de projet en quatre semaines
La méthode tient en cinq points, tous visibles dans le déroulé ci-dessus. Des critères de succès chiffrés et signés avant le premier jour. Un périmètre exclu écrit noir sur blanc. La validation humaine sous seuil de confiance dès la première version, pas en option pour plus tard. Un chef de projet nommé et joignable en direct, un rapport de fin de journée par développeur, un point hebdomadaire avec démonstration. Une intégration dans la stack existante, Laravel, React ou autre, plutôt qu'un service parallèle qu'il faudra raccorder ensuite.
Le passage en production se fait en 4 à 8 semaines selon la profondeur des actions métier à brancher. Le format SuperHote, trois profils sur 42 jours-homme, correspond à un copilote avec RAG hybride et actions transactionnelles. Pour cadrer votre cas, la page consacrée au développement d'agents IA sur mesure détaille les livrables et les prérequis côté client, à commencer par les accès et les référents nommés, puisque c'est là que les quatre semaines se gagnent ou se perdent.
