Projet de Hackathon

Les agents proposent, le code décide.

18 juillet 2026 · 6 min de lecture

Nous avons construit un système d'IA qui écrit des propositions commerciales, et nous lui avons interdit de faire les calculs.

Cette seule décision de design, plus que tout choix de modèle ou astuce de prompt, est ce qui a fait fonctionner Proposal Architect. Voici l'histoire de l'architecture que nous avons construite pour le Google for Startups AI Agents Challenge 2026, et de la règle qui l'a façonnée : les agents proposent, le code décide.

Pourquoi les propositions sont un bon problème pour des agents

Une proposition commerciale n'est pas une seule tâche. C'est une chaîne de compétences très différentes : lire un brief désordonné, cartographier les exigences, concevoir une architecture, décomposer le travail, estimer l'effort, fixer un prix et rédiger le tout sous une forme qu'un client peut réellement évaluer. Demandez tout cela à un seul prompt et vous obtenez quelque chose qui ressemble à une proposition et ne survit à aucun examen.

Les pipelines multi-agents existent exactement pour les problèmes de cette forme. Chaque compétence devient un agent spécialisé avec un contrat étroit ; le pipeline transporte l'état de l'un à l'autre ; et les parties qui ne doivent jamais être créatives (l'arithmétique) sortent complètement du modèle.

Le pipeline en six mouvements

Le flux se lit de gauche à droite : un brief brut entre ; les agents l'ancrent dans la connaissance de l'entreprise (grilles tarifaires, projets passés) ; un agent architecte conçoit la solution et sa structure de travail ; une étape déterministe calcule le coût et le ROI dans le code ; un critique adversarial conteste le brouillon ; et un compositeur assemble la proposition finale, à l'écran et en PDF à la marque.

Le cœur déterministe

Les modèles de langage sont convaincants en arithmétique et peu fiables en la matière, la pire combinaison possible pour un prix. L'étape de prix de Proposal Architect n'est donc pas un agent. C'est du Python pur : le modèle propose des entrées structurées (rôles, effort, hypothèses), et compute_price et compute_value font le calcul.

La frontière est défendue, pas seulement déclarée. Les nombres produits par le modèle sont validés avant d'entrer dans le calcul : les valeurs non finies et les quantités négatives sont rejetées d'emblée, si bien qu'une entrée hallucinée ne peut empoisonner ni le prix ni le ROI. Les mêmes entrées produisent toujours les mêmes nombres, ce qui signifie qu'un associé peut auditer n'importe quel chiffre du document jusqu'à ses entrées.

C'est la règle générale avec laquelle nous construisons : le modèle propose, le code décide. Partout où un nombre porte une conséquence métier (un prix, un score, un quota), il est calculé de manière déterministe, et le travail du modèle s'arrête à la suggestion des entrées.

Le critique qui conteste

Les premiers brouillons sont confiants et faux de manière subtile. La réponse du pipeline est un agent critique adversarial dont le seul travail est d'attaquer le brouillon : affirmations sans preuve, sections faibles, incohérences entre l'architecture et l'estimation. Les sections recalées repartent pour une passe, dans une boucle bornée, afin que la pression de qualité soit structurelle au lieu de dépendre d'une relecture attentive à 23 heures.

Ce que cette architecture apporte

Trois propriétés découlent du design au lieu d'être ajoutées après coup : la traçabilité (chaque exigence du brief correspond à une section de la réponse, avec un statut), l'auditabilité (chaque nombre se reproduit à partir de ses entrées) et la cohérence (la structure du document est imposée par le pipeline, pas par l'humeur du jour).

La partie honnête

Proposal Architect est né comme un système de hackathon : la connaissance sur laquelle il s'ancre est synthétique par design, et ce n'est pas (encore) un déploiement client. Ce que le build a validé, c'est l'architecture : la frontière déterministe, la boucle de critique et le patron d'ancrage ont survécu à des exécutions réelles, à une revue adversariale et à une vague de durcissement sécurité.

Cette architecture est le point. C'est la même règle que nous appliquons à tout ce que nous livrons chez Techmorphosys : de l'intelligence là où elle aide, du déterminisme là où ça compte.