Cas pratique : quand l'IA produit de la médiocrité industrielle

Cet article prolonge Appels d'offres et IA : vers une mutation silencieuse du marché, où l'on posait le constat : la plupart des approches actuelles automatisent la mauvaise chose. Ici, on entre dans le concret. Un cas réel. Un échec réel. Et ce qu'il nous apprend.

Le projet

Une ESN de taille significative -- plusieurs milliers de consultants, des centaines de réponses à appels d'offres par an. Le constat de départ est sensé : on passe trop de temps à rédiger, on a un historique riche de réponses gagnantes, pourquoi ne pas entraîner un modèle pour capitaliser dessus ?

Le projet est ambitieux. Budget de plusieurs millions d'euros. Développement offshore. Une équipe dédiée pendant plus d'un an. L'objectif : un outil interne capable de générer des réponses techniques à partir de l'historique des offres passées.

Plusieurs millions d'euros et plus d'un an de développement pour construire un copier-coller statistiquement optimisé.

Sur le papier, c'est du bon sens. En pratique, c'est une catastrophe annoncée.

L'erreur fondamentale : aucune ontologie

Le modèle a été entraîné sur des centaines de réponses passées. Des sections techniques, des paragraphes méthodologiques, des références projets, des engagements de service. En vrac.

Le problème : aucune structure sémantique n'a été construite en amont.

Le modèle ne distingue pas :

• Agile vs. Cycle en V -- deux philosophies de delivery radicalement différentes, mélangées dans le même corpus d'entraînement
• Kubernetes vs. architecture monolithique -- des paradigmes d'infrastructure opposés, traités comme des blocs de texte interchangeables
• Un CDC pour un ministère vs. un CDC pour une startup -- des contextes métier, des niveaux d'exigence, des cultures de décision qui n'ont rien en commun
• Une offre gagnante vs. une offre perdante -- aucune pondération. Le modèle apprend autant des échecs que des succès, sans le savoir

Résultat : le modèle a appris le style de l'ESN, pas son intelligence. Il sait produire des phrases qui ressemblent à des réponses d'appels d'offres. Il ne sait pas pourquoi ces phrases existent.

Le résultat : la machine à médiocrité

Après plus d'un an de développement et plusieurs millions investis, l'outil est livré. Les premiers tests sont révélateurs.

Prenons un cas concret. Un CCTP pour la refonte d'un SI de gestion des ressources humaines d'une collectivité territoriale. Le cahier des charges insiste lourdement sur :

• La reprise de données depuis un système legacy vieillissant
• L'accessibilité (RGAA)
• Un calendrier serré avec une mise en production avant les élections

Voici ce que produit le modèle (reconstitution anonymisée) :

Réponse générée par le modèle :

"Notre approche méthodologique s'appuie sur une démarche éprouvée combinant les meilleures pratiques Agile et les principes du cycle en V pour garantir un delivery de qualité. Notre équipe pluridisciplinaire mobilisera des experts techniques et fonctionnels pour assurer la réussite du projet. Nous proposons une architecture moderne, scalable et sécurisée, basée sur les standards du marché."

Tout est vrai. Rien n'est utile.

• "Combinant Agile et cycle en V" -- parce que le corpus contenait les deux, et le modèle a appris à ne froisser personne
• "Équipe pluridisciplinaire" -- phrase présente dans 90 % des offres d'entraînement
• "Architecture moderne, scalable et sécurisée" -- la trinité creuse, applicable à n'importe quel projet
• Aucune mention de la reprise de données (le vrai sujet)
• Aucune mention de l'accessibilité RGAA (une exigence réglementaire)
• Aucune mention du calendrier contraint (le risque principal)

Le modèle a produit la moyenne statistique de toutes les réponses passées. Une réponse médiane. Techniquement correcte. Stratégiquement vide.

Maintenant, comparons avec ce qu'un bid manager compétent aurait écrit :

Réponse contextualisée :

"Le risque principal de ce projet n'est pas technique -- c'est la reprise de données depuis [système legacy], dont la documentation est parcellaire et les formats non standardisés. Nous proposons un sprint 0 de 4 semaines dédié exclusivement à l'audit et au mapping des données existantes, avant tout développement. Cette approche sécurise le calendrier de mise en production que vous avez fixé à [date], en identifiant les blocages réels avant qu'ils ne deviennent des retards.

Sur l'accessibilité RGAA, nous intégrons un audit de conformité à chaque sprint, pas en recette finale. [Référence projet similaire avec résultat mesurable]."

La différence n'est pas dans la qualité rédactionnelle. Elle est dans la compréhension du problème.

La première réponse dit "on est bons". La seconde dit "on a compris votre douleur, voici comment on la traite". L'une rassure vaguement. L'autre convainc.

---

Le diagnostic

Pourquoi ça ne marche pas ? Parce que l'approche repose sur une hypothèse fausse : le passé contient les réponses au futur.

Entraîner un modèle sur vos offres passées, c'est lui apprendre à reproduire ce que vous avez déjà fait. Pas à comprendre ce que le client demande. C'est du copier-coller statistiquement optimisé.

Les problèmes structurels :

• Pas de segmentation sémantique. Le modèle ne sait pas que "Agile" dans un contexte bancaire et "Agile" dans un contexte industriel sont deux réalités différentes. Il a appris le mot, pas le concept.
• Pas de lien entre contexte et réponse. Le modèle génère des blocs de texte, mais il ne sait pas pourquoi tel bloc était pertinent pour tel marché. Il ne lit pas le CDC -- il le survole pour trouver des mots-clés déclencheurs.
• Pas de notion de qualité. Offre gagnante, offre perdante, offre moyenne -- tout a le même poids dans le corpus. Le modèle n'a aucun signal de ce qui fonctionne.
• Pas d'adaptation au client. Le modèle produit du "ESN-speak" générique. Il ne sait pas qui est en face, ce qui compte pour lui, ce qui le différencie des autres acheteurs.

En résumé : entraîner sur le passé sans structure sémantique, c'est apprendre à copier-coller intelligemment. Pas de compréhension. Pas de différenciation.

Pourquoi c'est un piège fréquent

Cette ESN n'est pas un cas isolé. Le raisonnement est tentant :

1. On a 10 ans d'offres dans nos serveurs
2. L'IA est bonne avec les données textuelles
3. Donc : on entraîne un modèle sur nos offres = avantage compétitif

C'est logique. C'est faux. Voici pourquoi :

• Le volume n'est pas la valeur. 500 réponses passées dont 200 ont perdu, 150 étaient médiocres et 150 étaient bonnes -- mais vous ne savez pas lesquelles sont lesquelles. Le modèle apprend un mélange.
• Le contexte est roi. Une réponse brillante pour un marché de 2022 est potentiellement obsolète pour un marché de 2026. Les technologies changent. Les réglementations évoluent. Les attentes clients mutent.
• L'avantage compétitif n'est pas dans les mots. Il est dans la capacité à comprendre ce que le client veut vraiment, au-delà de ce qu'il écrit. Aucun modèle entraîné sur vos anciennes offres ne sait faire ça.

L'alternative : raisonner avec l'avenir, pas avec le passé

Le bon paradigme n'est pas "qu'est-ce qu'on a déjà écrit de similaire ?". C'est : "qu'est-ce que ce client précis veut, pour lui, et comment lui apporter encore plus que ce qu'il demande ?"

Ça implique une architecture radicalement différente :

1. Questionner chaque information atomique du cahier des charges. Pas survoler. Pas résumer. Interroger. Chaque exigence, chaque contrainte, chaque formulation est un signal. "Le client a écrit 'impérativement' ici et 'si possible' là -- pourquoi ?" "Il y a 15 pages sur l'infrastructure et 2 sur l'applicatif -- qu'est-ce que ça dit de ses priorités ?" "Il mentionne trois fois la reprise de données -- c'est là qu'il a mal."

2. Ne pas raisonner avec le passé. L'historique peut informer (référence client, retour d'expérience). Il ne doit pas dicter. Chaque marché est un nouveau problème. Le client ne veut pas savoir ce que vous avez fait pour les autres -- il veut savoir ce que vous allez faire pour lui.

3. Raisonner avec l'avenir. Que veut ce client dans 3 ans ? Quel est le problème derrière le problème ? Qu'est-ce qu'il n'a pas osé écrire dans le CDC parce qu'il ne sait pas que c'est possible ? C'est là que se gagnent les marchés. Pas dans la capacité à recycler des paragraphes, mais dans la capacité à anticiper.

4. Construire une ontologie, pas un corpus. La différence entre une base de données de texte et une intelligence, c'est la structure sémantique. Savoir que "Agile" dans ce contexte signifie "Scrum avec des sprints de 2 semaines et une équipe de 5" -- pas "on est flexibles". Savoir que "architecture cloud-native" pour ce client signifie "on migre depuis du on-premise et on a peur" -- pas "Kubernetes everywhere".

Ce qu'il faut retenir

La différence entre "automatiser les appels d'offres" et "comprendre les appels d'offres" ne se situe pas dans le volume de données d'entraînement. Elle se situe dans deux choses :

• L'ontologie : la capacité à donner du sens aux informations, pas juste à les stocker
• Le raisonnement orienté client : la capacité à partir du besoin réel du client, pas de ce qu'on a déjà en stock

L'ESN de cette étude de cas a investi des millions pour construire un outil qui fait exactement ce qu'un bid manager fatigué fait un vendredi soir : du copier-coller à partir du dernier dossier qui ressemble vaguement au nouveau. Plus vite, certes. Mais pas mieux.

L'IA dans les appels d'offres n'est pas un problème de données. C'est un problème de cognition.

À retenir : Entraîner un modèle sur vos offres passées sans ontologie, c'est apprendre à copier-coller intelligemment. La différence entre automatiser et comprendre ne se situe pas dans le volume de données — elle se situe dans la capacité à donner du sens.

---

Chez TenderGraph, on ne recycle pas vos anciennes offres. On construit des agents capables de lire un cahier des charges comme un bid manager senior le ferait -- en cherchant le non-dit, en questionnant chaque exigence, en raisonnant pour le client qui est en face. Pas pour la moyenne de vos clients passés.

---

Lire aussi :

• Appels d'offres et IA : vers une mutation silencieuse du marché — Le constat macro : pourquoi le marché est en train de changer, et ce que ça implique.
• Le pire ennemi du bid manager : lui-même — L'autre face du problème : même sans mauvais outil, le cerveau humain sabote le process de réponse.
• Le mythe du executive summary — L'exec summary générique est le symptôme le plus visible de l'absence d'ontologie.
• Le piège du throughput — Produire plus vite sans ontologie = médiocrité industrielle à grande échelle.
• Pourquoi vos références clients ne convainquent personne — Le modèle recrachait des références sans pertinence. Voici pourquoi c'est un problème structurel, pas technologique.
• Ce que le CCTP ne dit pas — Le modèle de l'ESN ne détectait pas les ambiguïtés. Un système cognitif les signale et les transforme en questions.
• La révolution informationnelle — L'ESN a construit une machine à bruit industriel. Le cadre signal/bruit explique pourquoi.
• L'accélération des cycles d'avant-vente — Le bon outil accélère. Le mauvais accélère la médiocrité. Et ensuite, que fait-on du temps gagné ?
• Les compétences de l'avant-vente à l'ère de l'IA — L'ESN a sous-traité la compréhension à l'IA. La compétence manquante : la lecture du signal humain.
• Analyser un AO comme on devrait analyser l'actualité — Le modèle de l'ESN produisait l'équivalent de posts viraux : du bruit industriel avec la grammaire du signal.
• L'avant-vente est un exercice de commandement — Opérer sans carte : quand l'IA produit sans connaître le terrain.
• La soutenance : le moment où tout se joue — Le modèle de l'ESN ne préparait pas à la soutenance : face au jury, la médiocrité industrielle ne tient pas 5 minutes.
• Ce que l'évaluateur ne vous dira jamais — L'évaluateur détecte immédiatement une réponse recyclée sans ontologie — voici comment il note et ce qu'il pense vraiment.
• Un outil pour dix — L'ESN avait un outil de plus, pas un outil de mieux. La consolidation est le prérequis que personne ne traite.
• "Où en est le dossier ?" — la question qui tue l'avant-vente — Le modèle de l'ESN ne savait pas répondre à cette question non plus. Quand personne ne sait où en est le dossier, la médiocrité est garantie.