Analyse du besoin métier Serpe — appels d'offres

Analyse du dossier Drive exemple affaire_serpe/ (paysage/BTP, réponses aux appels d'offres publics), pour comprendre quelle donnée extraire, quels patterns, comment répondre concrètement, et comment refondre la web app. Fondé sur la lecture des documents réels (mémoires, CCTP, chiffrages, pièces administratives) + la synthèse d'ateliers Cathy/Olivier/Alexandre.

🔄 Mise à jour — audit multi-drive intégré. Une seconde instance a audité les 12 Shared Drives (275 134 fichiers) et produit une bibliothèque de blocs exploitable. Le doc 08 intègre ses conclusions et révise cette analyse là où l'échantillon local m'avait induit en erreur (notamment : la trame Serpe est morte depuis 2022 → ce sont les cadres clients qui imposent le plan et le barème qui pilote l'effort). Lire le doc 08 pour la vision consolidée et le plan de mise en œuvre.

Réponses directes aux 4 questions du brief

1. Quelle DATA extraire d'un AO ? → 18 champs structurés du DCE (doc 02 §5), classés en deux usages : qualification (type, acheteur, montant, lots, deadline, complexité, risque) et contrainte de génération (critères + pondérations, cadre imposé, nature des travaux, contraintes de site). Plus des synthèses IA générées à la lecture (résumé du besoin, contraintes clés, postes/quantités) — doc 05 §2.

2. Quels patterns entre les AO terminés ? → 5 axes (doc 05 §1) : type de prestation (clé de similarité n°1 : élagage / débroussaillage / sylvicole / génie éco / entretien EV / paysage-BTP), nature du marché (forfait / accord-cadre / pluriannuel), verticale émetteur (collectivité / EP / grand compte), cadré (~1/3) vs libre (~2/3), et issue (gagné/perdu — non concluant sur cet échantillon quasi 100 % perdu).

3. Comment répondre concrètement (les parties à remplir) ? → Le mémoire technique suit un squelette de 17 sections (doc 03 §2), déjà quasi-standard chez Serpe même sans cadre imposé. Trois natures de sections : figées (insérées telles quelles : suivi, réception, contrôle qualité, RSE, sécurité…), paramétrées (générées : contexte, contraintes/solutions, méthodologie par poste), sélection (piochées : références, engins, annexes). La section pivot « Réponses aux critères de jugement » se calque sur la grille du RC.

4. Quel est le process ? → 8 étapes (doc 04 §4), de la réception du DCE au dépôt : réception → prépa admin → étude & chiffrage (0210-0213) → rédaction SOPRE + mémoire → contrôle qualité (« la passoire ») → dépôt → négo → issue.

Les 3 insights structurants

1. Serpe a déjà un template maître. Deux mémoires d'affaires différentes sont quasi mot-pour-mot identiques (doc 03 §1). La génération par assemblage de blocs n'est pas un pari : c'est déjà la pratique manuelle, à outiller.

2. Il n'y a pas de source unique de vérité. Le dossier administratif est reconstruit à la main par agence, avec des sommaires différents entre agences (doc 04 §1). → Premier quick win : une bibliothèque de blocs versionnée, avant même la génération.

3. Le gabarit est élastique et piloté par les critères. Même ossature, densité proportionnelle à l'enjeu (5 à 117 pages) ; l'ordre/les titres suivent la grille de notation du RC (doc 03 §4). → l'éditeur doit être piloté par un mapping critère RC → section, réordonnable par AO.

La refonte proposée (doc 06)

Deux modules + un socle, dans cet ordre de valeur : - C. Bibliothèque & référentiels (source de vérité) — prérequis, quick win. - A. AO terminés (analyse read-only : carte d'identité + synthèses + stats) — démontre la valeur vite. - B. AO en cours (éditeur de mémoire section par section → assemblage) — le cœur métier.

L'écran clé est l'éditeur section par section (maquette doc 06 §5) : trame proposée depuis le RC, mémoire similaire suggéré (RAG par type de prestation), blocs figés pré-remplis, blocs paramétrés générés par Gemini, validation section par section, assemblage final avec intégration des visuels (le différenciant).

Ordre de lecture

Doc	Contenu
01 — Inventaire et typologie	Ce qu'est l'échantillon, cycle de vie d'un dossier, hétérogénéité
02 — Anatomie du DCE & data extractible	Le reçu client, les 18 champs à extraire
03 — Anatomie du mémoire technique	Les 17 sections, figées vs paramétrées, visuels
04 — Corpus réutilisable & process	Bibliothèque de blocs, admin, les 8 étapes
05 — Patterns & qualification	Patterns inter-AO, data de la vue read-only
06 — Refonte de la web app	Pages, parcours, maquettes de l'interface
07 — Schéma de données révisé	Évolutions Supabase pour porter tout ça
08 — Intégration audit multi-drive ★	Vision consolidée & plan révisé (cadre-pilote, blocs.jsonl, vertical slice)

★ Le doc 08 est le plus récent et prime sur les docs 03/05/06/07 là où il les révise (bandeaux de renvoi en tête de chaque doc concerné).

Angles morts & prochaines actions

1. Récupérer 2-3 vrais RC récents auprès de l'équipe → pondérations et cadres réels (absents de l'échantillon local — doc 02 §1). Seul vrai angle mort.
2. Analyser des dossiers gagnés → facteurs de victoire (échantillon quasi 100 % perdu — doc 03 §7).
3. ~~Croiser avec l'audit multi-drives~~ → fait : intégré au doc 08. Reste ouvert : la donnée win/loss (export Zoho code affaire → issue, demande partie à Serpe) — c'est ce qui fait passer de « conforme » à « compétitif » (doc 08 §7-8).
4. Valider la refonte (docs 06 + 08) et le schéma (docs 07 + 08 §6), puis attaquer le vertical slice (thème Moyens humains : cadre → blocs → réécriture Gemini → .docx) comme première brique de code (doc 08 §7).

Note : le synthese-dossiers-drive-appels-offres.md du dossier affaire_serpe/ (gitignoré) a servi de base ; son contenu est incorporé et enrichi ici, dans des documents versionnés.