Rédiger une proposition de financement sans inventer un seul chiffre

Flux

1. Ingestion. Un lien, un texte collé ou des fichiers (appel en PDF, gabarits DOCX et XLSX, annexes). Les fichiers vont dans le stockage blob, sous l'opportunité.
2. Extraction. Claude lit l'appel (PDF nativement) en un enregistrement structuré : bailleur, référence, échéances, lieux, secteurs, résultats attendus, critères pondérés, documents requis, clauses de protection des données. La sortie est validée par un schéma Zod avant d'être stockée.
3. Analyse des gabarits. Chaque DOCX ou XLSX est lu au niveau OOXML et cellule en un squelette de localisateurs. Le modèle décide quels localisateurs sont des créneaux à remplir, avec la consigne du bailleur et une longueur attendue. La carte des créneaux validée est mise en cache par empreinte : un bailleur qui réutilise son formulaire est reconnu la fois suivante.
4. Génération, créneau par créneau. À partir de l'appel, de la base de connaissances curée de l'organisation et des consignes du réviseur. Chaque créneau revient avec ses sources, un score de confiance et une liste de points à vérifier. Un fait absent de la base devient un marqueur [À COMPLÉTER].
5. Rendu en place. Le contenu est réécrit dans les fichiers d'origine : styles conservés, formules budgétaires conservées et décalées quand des lignes sont insérées. Les notes libres sont produites en Markdown, puis en Word.
6. Revue. Les réviseurs sont notifiés dans l'application et par courriel ; ils modifient des sections, en régénèrent certaines avec une consigne, assignent, approuvent et marquent la proposition soumise.
7. Veille. Un travailleur quotidien interroge les sources configurées (API du UN Partner Portal, pages HTML, flux RSS) et crée les nouvelles opportunités au fil de l'eau.

Portes humaines

Rien ne quitte l'organisation sans qu'un réviseur l'approuve. Le moteur rédige ; les personnes soumettent.

La régénération est ciblée : un réviseur régénère un créneau avec une consigne écrite, pas le document entier.

Les permissions suivent le RBAC de la plateforme : gestionnaires d'appels d'offres, administrateurs du siège et chefs d'équipe font tourner le moteur ; les gestionnaires financiers approuvent.

Ce qui ne part jamais au LLM

Les faits absents de la base de connaissances. Le prompt interdit d'affirmer quoi que ce soit sur l'organisation qui n'apparaît pas dans les fiches fournies ; le schéma impose une liste de points à vérifier sur chaque créneau.

La mise en forme du bailleur. Le modèle renvoie un contenu pour un localisateur ; la couche de rendu est propriétaire du document.

Décisions et pourquoi

Pourquoi des sorties structurées plutôt qu'une conversation. Le livrable est le fichier du bailleur. Un localisateur et un schéma forment un contrat d'interface ; du texte libre exigerait qu'un humain le recopie et dériverait.

Pourquoi l'OOXML cellule par cellule. Les bailleurs notent le formulaire qu'ils ont envoyé. Le réécrire en résumé perdrait les formules budgétaires, la numérotation et les consignes sur lesquelles les évaluateurs s'appuient.

Pourquoi une base de connaissances et des marqueurs. L'erreur la plus coûteuse dans une proposition est un chiffre faux affirmé avec assurance. Les faits manquants sont exposés, jamais devinés.

Pourquoi un coût par opportunité. Chaque génération additionne les jetons d'entrée, de sortie et de cache dans un compteur stocké sur l'opportunité : le prix d'un brouillon est connu avant qu'on le demande.

Pourquoi le cache de prompts. L'appel et les fiches de connaissances sont identiques d'un créneau à l'autre ; les mettre en cache garde un brouillon multi-créneaux abordable.

Chiffres

3 adaptateurs de sources (UN Partner Portal, HTML, RSS) surveillés chaque jour par un travailleur PM2.

5 modèles de données, un répertoire moteur avec extraction, analyse de gabarits, génération, rendu, sources et notifications, et 5 scripts en ligne de commande pour l'ingestion, la génération, la veille et l'amorçage des connaissances.

Composant d'Aria : 18 modules, 13 rôles RBAC, 63 modèles de données, 21 ADR, 6 versions, déployé sur Azure derrière Front Door et un WAF.

Pile technique

Next.js 14 · MongoDB sur Azure Cosmos DB · Azure Blob Storage · SDK Anthropic avec sorties structurées Zod et cache de prompts · traitement OOXML et XLSX · travailleurs PM2 · Terraform · Azure Pipelines