Vos revues de dossiers ne servent à rien — et l'IA va le prouver

Cet article prolonge L'accélération des cycles d'avant-vente, où l'on posait la question de ce qu'on fait du temps libéré par l'IA, et La révolution informationnelle, où l'on appliquait la théorie de Shannon au bid management. Ici, on descend d'un cran : on parle de ce qui se passe à l'intérieur de l'organisation qui produit la réponse.

Le théâtre des revues

Toute organisation structurée qui répond à des appels d'offres a un processus de revue. Trois niveaux, généralement. Ça s'appelle bronze / argent / or, ou bien R0 / R1 / R2, ou encore screening / mid-term / final review. Les noms changent. Le rituel est le même.

Revue bronze : on valide le Go/No-Go. Un PowerPoint de 8 slides. Le directeur commercial valide en 4 minutes. On passe au dossier suivant.

Revue argent : à mi-parcours. On présente l'avancement. Un nouveau PowerPoint, cette fois 15 slides. On découvre que le solutionneur n'a pas encore commencé. Le bid manager dit que "c'est en cours". On prend note. On passe au dossier suivant.

Revue or : avant soumission. On présente le mémoire technique "finalisé". Un troisième PowerPoint — 25 slides. Le directeur technique découvre le contenu pour la première fois. Il fait des remarques. Trois d'entre elles sont structurantes. Il est 17h30 la veille de la date limite.

Le problème n'est pas le nombre de revues. C'est que chaque revue crée un nouveau fichier, un nouveau compte-rendu, un nouveau jeu de logs — sans lien avec les précédents. Et 90 % de l'information est redondante.

Ce qui dysfonctionne vraiment

La redondance comme source d'entropie

Shannon l'a démontré : la redondance dans un canal de communication n'est utile que si elle sert à corriger les erreurs (Shannon, C.E., A Mathematical Theory of Communication, Bell System Technical Journal, 1948). Quand la redondance ne sert pas à corriger — quand elle empile du bruit — elle augmente l'entropie. L'information devient plus difficile à trouver, pas plus facile.

C'est exactement ce qui se passe dans vos revues. Le CR de la R0 contient le contexte du dossier. Le CR de la R1 le répète — avec des variations mineures. Le CR de la R2 le répète encore — avec d'autres variations. Trois versions du contexte. Aucune n'est exactement la même. Laquelle est la bonne ?

Trois niveaux de revue. Sept fichiers minimum. Cinq e-mails de convocation. Et une information stratégique — les décisions réelles, les risques acceptés, les arbitrages — qui n'est consignée nulle part de manière explicite.

Les décisions implicites

Le vrai poison, c'est ce qui n'est pas écrit.

"On a décidé de ne pas répondre au lot 3." Où est-ce documenté ? Dans un e-mail envoyé à trois personnes un mardi à 22h. Pas dans le CR. Pas dans le PowerPoint. Pas dans le fichier de suivi.

"Le client a laissé entendre que la continuité de service était son critère principal." Qui l'a noté ? Le commercial, dans sa tête. Peut-être dans un mail. Certainement pas dans le dossier structuré.

"On a décidé de positionner un profil junior sur le lot applicatif pour rester compétitif sur le prix." Qui a pris cette décision ? Quand ? Sur la base de quelle analyse ? Personne ne sait. Mais tout le monde vit avec les conséquences.

Les décisions les plus structurantes d'un dossier sont celles qui ne sont jamais formalisées. Elles vivent dans les conversations, les e-mails, les silences des réunions. Et quand il faut les retrouver — trois semaines plus tard, au moment de rédiger le mémoire technique — c'est le vide.

L'encodage illisible

Retrouver l'information dans un dossier d'appel d'offres en cours est un exercice de fouille archéologique.

Le fichier s'appelle MT_v3_final_corrigé_AM_VF2.docx. Il est dans un sous-dossier de Teams. Ou dans SharePoint. Ou dans le drive du bid manager. Trois versions coexistent. Aucune n'est taguée. Aucune n'est liée au CR qui a motivé les corrections. Aucune n'est reliée aux exigences du CCTP qu'elle est censée couvrir.

Le solutionneur qui arrive en cours de route passe une demi-journée à comprendre "où on en est". Le directeur technique qui fait la revue or n'a aucun moyen de savoir quelles décisions ont été prises en R0 et R1. Il relit tout. Il refait le travail. Il pose les mêmes questions.

C'est le coût réel de l'entropie informationnelle : pas la perte d'information, mais le temps passé à la retrouver.

Ce que l'IA révèle — et ce qu'elle ne résout pas

Ce que l'IA fait très bien aujourd'hui

Donnez à un système IA correctement architecturé l'intégralité d'un dossier — CCTP, CR de revues, échanges, mémoire technique en cours — et il fait en quelques minutes ce qu'aucun humain ne peut faire en une journée :

• Détecter les redondances : identifier les paragraphes copiés-collés entre les CR, les slides qui se répètent d'une revue à l'autre, les formulations qui divergent sans que la décision sous-jacente ait changé.
• Tracer les décisions : extraire de tous les documents et échanges les moments où une décision a été prise, et construire un journal de bord chronologique que personne n'a jamais rédigé.
• Croiser les couches : relier une exigence du CCTP à la section du mémoire technique qui y répond, au risque identifié en R1 qui la concerne, et à la décision de R0 qui a orienté la stratégie de réponse.
• Signaler les trous : identifier les exigences sans réponse, les risques sans plan de mitigation, les décisions sans justification tracée.

L'IA ne remplace pas la revue. Elle rend visible ce que la revue cachait : les zones d'ombre, les décisions fantômes, les incohérences entre ce qui a été décidé et ce qui a été écrit.

Ce que l'IA ne résout pas

L'IA peut analyser n'importe quel document. Mais elle ne peut pas analyser ce qui n'a jamais été écrit.

Si votre commercial a noté les insights du client dans sa tête, l'IA ne les trouvera pas. Si votre décision de Go/No-Go est un "oui" verbal en fin de réunion, l'IA n'a rien à tracer. Si votre solutionneur a fait un arbitrage technique dans un coin de son cahier, l'IA ne le verra pas.

Le problème n'est pas l'IA. Le problème, c'est ce que vous lui donnez à manger.

Ce que vous devez changer — avant même de parler d'outil

Apprendre à encoder pour les machines

Le passage à l'ère de l'IA agentique impose un changement fondamental dans la manière dont les équipes formalisent l'information. Ce n'est pas une question d'outil. C'est une question de discipline cognitive.

Arrêter d'être évasif. "La situation est complexe et nécessite une analyse approfondie" ne veut rien dire — ni pour un humain, ni pour une IA. "Le lot 2 présente un risque de sous-dimensionnement : 3 ETP prévus pour 12 applications, ratio incompatible avec le SLA exigé (99,5 %)" est une information exploitable.

Lier chaque information à un enjeu. Un fait isolé est du bruit. Un fait relié à une exigence, un risque ou une décision est un signal. "Le client utilise Oracle" est un fait. "Le client utilise Oracle → contrainte d'intégration avec le module RH existant → exigence CCTP §4.3.2 → risque d'incompatibilité avec notre stack PostgreSQL" est une chaîne décisionnelle que l'IA peut exploiter.

Être explicite sur les décisions. Chaque décision devrait être une phrase structurée : Quoi a été décidé, Pourquoi, Par qui, Quand, et Quelles conséquences sur le dossier. Pas un "on a acté le fait de..." noyé dans un paragraphe de compte-rendu.

Stocker différemment

Le problème des fichiers PowerPoint n'est pas leur format. C'est qu'ils sont des conteneurs fermés. L'information entre dans un .pptx et n'en ressort jamais — sauf si un humain la recopie manuellement dans un autre fichier.

L'information stratégique d'un dossier devrait vivre dans un système structuré, pas dans des fichiers éparpillés. Un graphe de connaissances, une base de faits, un journal de décisions — peu importe la forme technique. Ce qui compte, c'est que l'information soit :

• Atomique : un fait = une entrée. Pas un paragraphe qui mélange trois informations.
• Reliée : chaque fait est lié à ses sources (exigence CCTP, CR de revue, e-mail) et à ses conséquences (section du mémoire, risque, décision).
• Versionnée : on sait quand un fait a été créé, modifié, invalidé. Pas "v3_final_corrigé".
• Interrogeable : on peut demander "quelles sont les décisions prises en R1 qui impactent le lot 2 ?" et obtenir une réponse en secondes.

Revoir le rythme des revues

L'IA compresse le temps de production. Ce qui prenait 3 semaines prend 3 jours. Mais les revues sont toujours calées sur l'ancien calendrier : R0 à J+3, R1 à J+10, R2 à J+18.

Quand la production est finie à J+5, que fait-on entre J+5 et J+18 ? On attend. On peaufine des détails. On crée de l'entropie — des modifications mineures, des reformulations, des ajustements cosmétiques qui n'ajoutent aucune valeur mais créent de nouvelles versions.

Le nouveau rythme devrait être :

1. R0 structuré (Go/No-Go) : avant tout, un vrai Go/No-Go avec scoring (Comment décider de répondre ou non). Pas 4 minutes. 30 minutes. Avec des données.
2. Production compressée : 2-3 jours avec l'IA. Extraction, structuration, première rédaction.
3. Revue unique de fond : une seule revue, mais dense. Red team. Challenger la stratégie, pas la mise en page. Le directeur technique lit le fond, pas les slides.
4. Sprint de finalisation : 1-2 jours pour intégrer les retours structurants.

Quatre étapes au lieu de sept. Un seul flux d'information au lieu de trois couches redondantes.

La vraie transformation : au-delà de l'outil

Ce que TenderGraph vise

TenderGraph n'est pas un outil de revue. C'est un système cognitif qui impose une discipline d'encodage.

Quand RequirementMiner extrait 1 382 exigences d'un CCTP de 500 pages, il ne produit pas un fichier de plus. Il crée un graphe structuré — chaque exigence typée, classée, priorisée, reliée aux autres. Quand TITAN orchestrera la réponse complète, chaque décision, chaque arbitrage, chaque version sera tracée dans un journal chronologique exploitable par l'humain et par la machine.

Mais TenderGraph ne peut rien si l'organisation continue à encoder l'information comme en 2015. Si le commercial range ses insights dans sa tête. Si le solutionneur travaille dans un fichier local. Si le directeur technique découvre le dossier la veille de la deadline.

La lenteur de transformation comme point de friction

Le frein principal n'est pas technologique. Il est organisationnel.

Les équipes savent que leurs revues sont du théâtre. Les bid managers savent que leurs CR ne sont pas lus. Les solutionneurs savent que leurs arbitrages ne sont pas tracés. Mais le système fonctionne "suffisamment bien" — on gagne assez de marchés pour ne pas remettre en question le processus.

Jusqu'au jour où un concurrent qui a fait la transformation gagne le marché que vous pensiez acquis. Pas parce qu'il a un meilleur outil. Parce que son équipe encode l'information de manière exploitable, que son IA peut relier chaque exigence à une réponse argumentée, et que sa revue unique de fond a détecté la faille stratégique que vos trois revues PowerPoint ont manquée.

La bonne nouvelle : cette transformation ne nécessite pas de tout renverser. Elle commence par trois changements simples — encoder les décisions explicitement, relier les faits aux enjeux, et remplacer la redondance par la traçabilité. Le reste suit.

Par où commencer

1. Formaliser les décisions : à partir de demain, chaque réunion de revue produit non pas un CR narratif mais un journal de décisions structuré (Quoi / Pourquoi / Par qui / Impact).
2. Tuer la redondance : un seul document vivant par dossier, pas trois PowerPoints. L'IA peut générer les slides de revue à partir du document vivant — pas l'inverse.
3. Tester avec l'IA : prenez votre dernier dossier. Donnez l'intégralité des fichiers à un LLM. Demandez-lui : "Quelles décisions ont été prises ? Quels risques ne sont pas couverts ? Quelles exigences n'ont pas de réponse ?" Les trous qu'il révèle sont les trous que vos revues n'ont pas vus.

---

Ce que fait TenderGraph

RequirementMiner transforme un CCTP en graphe structuré d'exigences — pas en fichier de plus. TITAN (à venir) orchestrera le dossier complet avec traçabilité intégrée : chaque fait, chaque décision, chaque version, reliée et interrogeable. L'objectif n'est pas de remplacer vos revues — c'est de rendre visible ce qu'elles cachent, et d'imposer une discipline d'encodage qui transforme le bruit en signal exploitable.

Découvrir TenderGraph →

---

Lire aussi

• L'accélération des cycles d'avant-vente : et après ? — Que fait-on du temps libéré par l'IA ?
• La révolution informationnelle : pourquoi l'IA amplifie le bruit autant qu'elle peut l'éliminer — Shannon appliqué au bid management
• Répondre à un appel d'offres : ce que les guides ne vous diront jamais — Go/No-Go, stratégie, organisation
• L'avant-vente est un exercice de commandement — Planification, friction, commandement par mission
• Comment rédiger un mémoire technique qui fait gagner des marchés — Encodage du signal, structure par le barème
• Biais cognitifs et appels d'offres — Pourquoi les humains reproduisent les mêmes erreurs
• La soutenance : le moment où tout se joue — Les revues de dossiers ne préparent pas à la soutenance. Le pilotage réel inclut la préparation du moment décisif.
• Ce que l'évaluateur ne vous dira jamais — Les revues bronze/argent/or ne simulent jamais le regard de l'évaluateur. Comprendre sa grille changerait tout le processus de revue.
• Un outil pour dix — Le pilotage échoue quand l'information est dispersée entre dix outils. La consolidation est le prérequis d'un pilotage réel.
• "Où en est le dossier ?" — la question qui tue l'avant-vente — Les revues bronze/argent/or ne répondent pas à cette question — elles la ritualisent. Le vrai pilotage exige une réponse en temps réel, pas un PowerPoint trimestriel.