De l'IA en libre-service à l'architecture : ce qu'un PM apprend en pilotant lui-même le code

Deux voix dans ce texte : le PM intrigué par ce que l'IA change pour une équipe DevSecOps agile, et le bricoleur qui a tout construit lui-même pour comprendre. Aucune des deux ne cherche à convaincre — juste à raconter.

Ce texte n'a pas de but académique ni professionnel. C'est le récit d'une exploration personnelle : comment un besoin tout bête — arrêter de perdre des heures à comparer des prix — m'a traîné d'un simple chat jusqu'à une petite app multi-agents qui tourne sur un serveur. À chaque étape, deux voix se parlent dans ma tête. Je les garde séparées ici, volontairement.

Acte 1 — Le simple chat, et le mur

Le bricoleur : ça commence toujours comme ça. Un chat, un prompt, « trouve-moi le meilleur prix pour X ». Ça marche, une fois, pour un produit. Ça casse dès qu'on demande la même chose dix fois de suite sur dix marchands différents : même prompt, réponses dans des formats différents, un marchand oublié sur deux, aucune façon de vérifier ce qui vient d'être affirmé. Le mur arrive vite : un chat est fait pour converser, pas pour répéter fidèlement une tâche cent fois de suite.

Le PM : ce qui m'accroche à ce moment-là, ce n'est pas la limite technique — c'est la vitesse à laquelle une seule personne, avec une seule fenêtre de chat, prototype quelque chose qui aurait exigé une petite équipe il y a deux ans. Ça change radicalement ce qu'un product manager peut valider seul, avant même de parler budget ou ressources à une équipe DevSecOps.

Acte 2 — Pourquoi un seul agent ne suffit plus

Le bricoleur : la réponse évidente, c'est de découper. Une IA qui qualifie le besoin. Une autre qui lit une page produit et en extrait des faits. Une troisième dont le seul travail est de retrouver une adresse exacte quand la première a échoué. Ça paraît simple sur papier. En pratique, la première version de ce découpage a marché parfaitement sur deux marchands — et a échoué en silence sur un troisième, sans erreur, sans message, juste une absence. Il a fallu apprendre à ne jamais faire confiance à un silence : une IA qui ne trouve rien ne dit pas toujours qu'elle n'a rien trouvé.

Le PM : je reconnais ce pattern. C'est exactement ce qu'une équipe DevSecOps agile fait déjà — séparer les responsabilités, garder chaque pièce petite et testable isolément, ne jamais laisser une seule tâche porter trop de logique à la fois. La différence, c'est qu'ici une partie de l'équipe est faite d'agents IA plutôt que de personnes. Ça ne change pas les principes de gouvernance d'équipe — ça les rend juste plus urgents, parce qu'un agent silencieux qui échoue ne va pas lever la main en réunion.

Acte 3 — Sortir du bac à sable

Le bricoleur : tant que tout tourne dans un terminal, sur ma machine, je peux ignorer plein de problèmes. Le moment où ça doit tourner sans moi — planifié, accessible, fiable — tous ces problèmes reviennent d'un coup : où vivent les clés d'accès si ce n'est plus mon ordinateur qui les tape, que faire quand deux appels partent en même temps et que le fournisseur en refuse un sur deux, comment savoir si ça a planté cette nuit sans que je sois là pour le voir. Passer en serverless n'était pas un choix d'élégance technique — c'était la seule façon de faire disparaître ces angles morts.

Le PM : c'est le moment MVP-vers-production, identique à n'importe quel projet, même à un seul utilisateur. Les mêmes portes s'ouvrent : revue de sécurité minimale (aucun secret exposé), contrôle de coût, résilience sans supervision humaine continue. Un projet perso n'est pas dispensé de ces gates juste parce qu'il n'a qu'un seul utilisateur — il force juste à les traverser seul, sans équipe pour partager la charge.

Acte 4 — Benchmarker au lieu de croire

Le bricoleur : deux moteurs de recherche IA se sont retrouvés côte à côte dans le pipeline — l'un pour une découverte large, l'autre pour une relecture ciblée quand le premier échouait. Chacun propose plusieurs niveaux d'effort (bas, moyen, élevé) : plus l'effort est haut, plus la réponse est fouillée, et plus elle coûte cher en jetons consommés. La seule façon de choisir, ça a été de tester les trois niveaux sur les mêmes vraies requêtes et de regarder où la courbe coût/qualité casse.

Les ordres de grandeur mesurés (approximatifs, pas audités) :

Résultat : effort moyen pour le premier balayage large (il couvre l'essentiel sans payer le prix du niveau élevé), effort bas pour la relecture ciblée (la précision supplémentaire du niveau élevé ne changeait presque rien quand l'adresse exacte était déjà connue). Une sonde de dix produits réels tournée pour valider une hypothèse a coûté de l'ordre de 0,20 $ en appels réels — assez bas pour re-mesurer souvent, assez réel pour ne pas être gratuit à chaque doute.

Le PM : c'est là que la rentabilité devient tangible plutôt qu'un acte de foi. Chaque recherche complète revient à quelques cents — traçable, pas estimée — contre deux heures de comparaison manuelle. Même en comptant généreusement le temps passé à construire et ajuster le pipeline, le seuil de rentabilité arrive après une poignée d'utilisations réelles. C'est la même logique qu'on applique à n'importe quel outil en entreprise — coût par unité de valeur livrée — juste à l'échelle d'un seul utilisateur.

Acte 5 — Les mains sur le volant

Les deux voix, ensemble : peu importe combien de couches on empile, le pipeline ne tourne jamais vraiment seul. Un timeout qui fait échouer un appel sans prévenir. Une URL qui répondait hier et qui est morte aujourd'hui. Un modèle qui invente un chiffre avec la même assurance qu'un chiffre réel — l'IA n'hésite jamais avant d'halluciner, elle le fait gratuitement et sans prévenir. Un patron qui semblait fiable sur dix essais et qui se casse au onzième, sans raison visible.

Aucun de ces incidents n'est un échec d'architecture. C'est le coût normal de laisser une machine agir sans supervision continue. On peut aller très vite avec l'IA — beaucoup plus vite qu'à la main — mais sans cadrage ni vérification à chaque étape, la fusée perd son orbite sans que personne ne s'en rende compte avant qu'il soit trop tard : du temps perdu, de l'argent perdu, pour une affirmation qui n'avait jamais été vraie. Garder les mains sur le volant, concrètement, ça veut dire : ne jamais publier une réponse d'IA sans un indicateur de confiance qui l'accompagne, et accepter qu'un système qui échoue parfois en silence doit toujours être supposé silencieux jusqu'à preuve du contraire.

Les niveaux de recherche et leur coût, en chiffres

Ces chiffres sont des ordres de grandeur mesurés en cours de route, pas un audit financier — largement assez précis pour une décision d'architecture, pas pour un rapport comptable.

L'architecture, du chat simple au kit complet

La pile technique assemblée pour en arriver là :

• Modèle de langage : Claude (Anthropic) — côté client pour la conversation, côté serveur pour arbitrer les résultats de recherche
• Moteurs de recherche IA : Perplexity (effort bas/moyen selon l'étape) + Tavily (découverte d'adresse)
• Hébergement : Vercel, fonctions serverless
• Runtime : Node.js, JavaScript natif côté front (aucun framework)
• Tests : le test runner natif de Node, sans dépendance externe
• Intégration continue : GitHub Actions — un pipeline pour les tests unitaires à chaque push, un pipeline séparé déclenché seulement sur le code sensible pour les bancs d'essai réels
• Rapports de benchmark : publiés en JSON sur des branches Git dédiées, consultables sans refaire tourner l'appel
• Secrets : uniquement en variables d'environnement côté hébergeur et CI, jamais dans le dépôt de code

Note méthodologique

Un format court, emprunté à la recherche, pour rester honnête sur ce que ces chiffres valent vraiment :

Échantillon — dix produits réels, cinq catégories, un seul marchand creusé en profondeur côté lecture.

Méthode — une sonde dédiée appelle directement les API de recherche (hors pipeline de production) et mesure deux taux distincts : découverte (le marchand est-il trouvé ?) et rétention (est-il retenu comme meilleure offre ?).

Limites — aucun groupe de contrôle, aucune répétition sur plusieurs semaines, un seul projet, un seul couple d'outils testé.

Ce qu'on a trouvé en cherchant des comparatifs existants — peu. Très peu de retours d'expérience publics détaillent ce couplage précis — un moteur de découverte large et un moteur de lecture ciblée, benchmarkés ensemble sur un vrai cas d'usage de prix, avec des coûts réels mesurés plutôt qu'estimés. Ce n'est pas une affirmation qu'il n'existe rien — seulement que la recherche n'a rien remonté d'assez précis pour être cité ici. Le format qui reste empruntable, même sans littérature à citer : sonde, mesure, décision documentée.

Le budget, en toute transparence

L'ensemble du projet — sondes, bancs d'essai, utilisation réelle — a coûté quelques dollars au total en appels API. Pas quelques milliers. Quelques dollars.

Pour ce prix, je n'ai trouvé nulle part ailleurs une formation aussi dense sur l'orchestration multi-IA, le benchmarking de modèles de recherche, et la mise en production réelle d'un pipeline agentique — secrets, limites de débit, CI, le tout. À ce ratio coût / apprentissage, c'est un investissement hors norme.

Deux images pour finir

La première, c'est celle que 90 % des gens verraient s'ils ouvraient l'app : une fenêtre de chat, une question posée en langage normal, une réponse qui arrive quelques minutes plus tard sous forme de tableau clair. Rien d'impressionnant à regarder. C'est le but.

La seconde, c'est ce qu'il y a derrière cet écran : plusieurs agents IA avec des rôles distincts, deux moteurs de recherche benchmarkés et réglés à des niveaux d'effort différents selon l'étape, un suivi de coût à chaque appel, une infrastructure serveur qui isole les clés d'accès, et quelqu'un — moi — qui reste la dernière ligne de vérification avant de croire ce qui s'affiche. L'écart entre les deux images, c'est exactement la leçon : on peut faire énormément avec l'IA, et aller très vite, mais seulement si quelqu'un garde la main sur le volant pendant que ça tourne.

En résumé

Ceci n'est pas un article académique, et ça n'essaie pas de prouver quoi que ce soit à une équipe ou à un marché. C'est le récit d'une exploration initiatique personnelle — un besoin tout simple qui a traîné un PM curieux et un bricoleur têtu jusque dans les coulisses de l'IA, avec ses rebondissements, ses benchmarks, ses coûts réels et ses mains restées sur le volant du début à la fin. Rien de plus qu'un partage d'expérience.