Requirement ou contrainte : pourquoi, en design, nos agents ont cessé d’explorer

Nous avons récemment réalisé un relaunch de site web avec une approche agentique. Environ 1 000 URL à reprendre, l’ancien système de contenu ramené au rôle de base de données, et un agent chargé de l’exploitation éditoriale. Pour que les agents sachent quoi produire, nous avions largement pré-spécifié le projet.

Le résultat : une exécution très solide et, de fait, aucun design.

Les agents ont livré. Mais à chaque question de forme, ils se sont raccrochés à ce qui était déjà là : briefs, exigences fonctionnelles, liste de modules, champs de données. Rien n’est revenu que nous n’ayons déjà écrit nous-mêmes. Le processus créatif n’a pas eu lieu. Nous l’avions spécifié hors d’existence.

Mon premier réflexe a été d’y voir un excès de contexte. C’était inexact.

Une contrainte façonne un espace de solution, une exigence referme l’espace-problème

L’erreur ne tenait pas à la quantité. Elle tenait au statut donné au contexte. Nous avions intégré la phase de design dans une feuille de route constituée, pour le reste, d’exigences. De ce fait, la phase de design est devenue… une exigence.

Il existe une preuve très nette, antérieure à toute discussion sur les agents.

En 2014, Rahul Mohanani, Paul Ralph et Ben Shreeve ont présenté à l’International Conference on Software Engineering une étude randomisée avec 42 participant·e·s. Les deux groupes ont reçu des consignes de contenu identiques pour la même tâche de design. Pour un groupe, on les appelait « requirements », pour l’autre « ideas ». Rien d’autre ne changeait.

Le groupe « requirements » a produit des designs significativement moins originaux (Mann-Whitney U = 116,5, p = 0,004).

Rien que le mot. Les auteurs nomment cet effet « requirement fixation ».

Une étude de suivi de la même équipe, publiée en 2022 dans IEEE Transactions on Software Engineering, a observé 42 designers en 21 binômes au travail. Recevoir des exigences sous forme de gabarits conduit à accepter sans recul sa première idée et à ne jamais y revenir. La recommandation des auteurs est littérale : si la créativité prime, évitez les gabarits d’exigences et la sur‑structuration, la sur‑simplification et la sur‑rationalisation des problèmes.

Nous avons fait les trois, dans le même document.

• 42 participant·e·s – Étude randomisée avec consignes identiques
• Mann-Whitney U = 116,5, p = 0,004 – Originalité significativement plus faible avec « requirements »
• 42 designers en 21 binômes – Les gabarits d’exigences favorisent la fixation précoce

Pourquoi les agents échouent ici comme les humains

La design fixation n’est pas nouvelle. Jansson et Smith l’ont décrite en 1991 dans Design Studies : exposé à un exemple avant une tâche de design, on en reprend les traits — y compris les erreurs qu’ils avaient introduites à dessein. Même nombre d’esquisses, mais moins de flexibilité et moins d’originalité. Et cela valait aussi pour des ingénieurs confirmés, pas seulement des étudiant·e·s.

On mesure aujourd’hui le même effet avec des agents. Un travail de Sanjith Vigraham, publié cette année, étudie précisément notre cas : exploration de design agentique (plutôt qu’implémentation), sur plus de 2 700 itérations et sept conditions de contexte. Deux résultats sont directement actionnables.

Premièrement, un même type d’artefact améliore nettement l’exploration pour certaines tâches et la dégrade jusqu’à 46 % pour d’autres. Sur plusieurs tâches, un document non pertinent l’emporte sur un document pertinent.

Deuxièmement — et c’est l’explication de notre projet : l’étroitesse issue des données d’entraînement peut être desserrée par des signaux perturbateurs. Celle qui vient d’une instruction explicite, non. Si vous figez l’agent sur une solution via un briefing, aucun contexte additionnel ne l’en sortira.

Précision sur la robustesse : auteur unique, un modèle testé, pas de peer‑review. Pertinent pour éclairer un mécanisme, pas pour en faire une loi.

En parallèle, un travail plus large de Laban et collègues chez Microsoft et Salesforce, sur 200 000 conversations simulées : la baisse moyenne de performance au fil de plusieurs tours est de 39 % par rapport à un tour unique. Le mécanisme est identique : les modèles formulent tôt des hypothèses, produisent une solution finale prématurée, s’y fient et, une fois engagés dans la mauvaise direction, ne reviennent pas en arrière.

• 2 700 itérations, 7 contextes – Exploration de design agentique étudiée
• jusqu’à 46 % – Dégradation de l’exploration selon le type d’artefact
• 39 % – Baisse de performance sur plusieurs tours de conversation

Le contexte est un budget, pas un stock

Anthropic en fournit l’explication mécaniste dans son propre guide de Context Engineering. Les modèles ont un « budget d’attention », et chaque token supplémentaire l’entame. La cause est architecturale : n tokens induisent n² relations, d’où une tension naturelle entre volume de contexte et acuité de l’attention. Leur objectif, en leurs termes : la quantité minimale de tokens au signal élevé. Et, explicitement contre notre erreur : ils déconseillent d’entasser dans le prompt une liste à rallonge de cas particuliers.

Deux mesures me paraissent probantes.

Chroma a testé 18 modèles sur près de 195 000 appels, en maintenant la difficulté de la tâche constante tout en ne faisant varier que la longueur d’entrée. L’effet de la quantité est ainsi isolé. La comparaison qui marque : 300 tokens d’entrée focalisée battent 113 000 tokens de texte intégral — pour tous les modèles testés.

Distyl AI a soumis 20 modèles à jusqu’à 500 instructions simultanées. À 500, le meilleur modèle de frontière atteint 68 % de conformité aux consignes. Un détail a une conséquence directe pour les longues spécifications : avantage systématique aux instructions placées tôt. Ce qui figure en fin de document est moins bien suivi que ce qui se trouve au début.

Dans notre projet, c’était mesurable avant d’être sensible. Avant la première question de fond, nous accumulions 1 500 à 3 000 lignes de contexte pré‑chargé, plus deux à trois minutes d’attente par requête.

• 18 modèles, 195 000 appels – Effet de la longueur d’entrée isolé
• 300 tokens vs. 113 000 tokens – L’entrée focalisée bat le texte intégral sur tous les modèles
• 20 modèles, 500 instructions – Meilleur modèle à 68 % de conformité
• 1 500–3 000 lignes + 2–3 minutes – Contexte pré‑chargé et latence par requête dans le projet

La solution évidente répète la même erreur, sous un autre habillage

Ma première idée de correctif était d’ouvrir la phase de design et de la nourrir de références souhaitées, de bonnes pratiques et de sources visuelles. J’aurais répété l’erreur.

Wadinambiarachchi et collègues l’ont montré à CHI 2024 avec 60 participant·e·s. Un appui par générateur d’images IA pendant l’idéation a renforcé la fixation sur le premier exemple. Les participant·e·s ont produit moins d’idées, avec une variance et une originalité moindres que le groupe témoin.

Des pages de référence en début de phase de design ne créent pas de liberté. Elles agissent comme un ancrage qui retient tout le reste.

Ce que nous faisons désormais autrement

1. Brief de mission plutôt que liste d’exigences. Raison d’être, cibles, définition du succès. Délibérément sans liste de modules.
2. Un premier passage sans aucun contexte. Il montre jusqu’où le système va de lui‑même. C’est le diagnostic le moins coûteux du processus.
3. Divergence avec le moins de modèles possibles. Si l’on ouvre, c’est avec des anti‑modèles (« à ne pas faire, et pourquoi »), pas avec des best practices.
4. Formaliser les exigences après la décision de forme. Périmètre fonctionnel, champs de données, limites de gouvernance viennent ensuite, pas en parallèle.
5. Les garde‑fous en dernier. En phase d’exécution, ils sont à leur place, car des runs longs et autonomes y sont l’enjeu.

Cela signifie‑t‑il que nous planifions moins ?

Non. Le lien entre consignes et créativité n’est pas linéaire ; il suit une courbe en U inversé. Acar, Tarakci et van Knippenberg l’ont établi en 2019 dans le Journal of Management en synthétisant de nombreuses études : trop peu de consignes freinent la créativité autant que trop de consignes. Le bon milieu la stimule.

Dans le cadre de l’ingénierie agentique, le réflexe actuel va dans l’autre sens. Le Spec‑Driven Development, c’est‑à‑dire la spécification complète en amont comme artefact directeur, est la méthode du moment. Colin Eberhardt, de Scott Logic, a construit la même fonctionnalité deux fois, une avec un tel outil et une sans. Avec : 689 lignes de code, 2 577 lignes de texte de spécification et trois heures et demie de revue, plus un défaut que la spécification n’a pas empêché. Sans : un quart d’heure de revue, aucun défaut. Le Technology Radar de Thoughtworks a placé la méthode en novembre au niveau « Assess », en notant qu’on réapprend peut‑être ici une leçon amère : des règles détaillées écrites à la main pour l’IA ne passent pas à l’échelle.

• 2 577 lignes de spécification – Volume dans l’approche « Spec »
• 3,5 heures de revue – Effort avec spécification complète en amont
• 15 minutes de revue – Effort sans outil de spécification
• 0 défaut vs. 1 défaut – Qualité des résultats comparée

Notre feuille de route n’était pas fausse. Elle n’avait qu’un seul mode, l’exécution.

Questions fréquentes sur Requirement vs. Contrainte dans le design agentique (FAQ)

Comment distinguer concrètement une requirement d’une contrainte ?

Les requirements décrivent ce que le système doit livrer et ferment souvent des options trop tôt. Les contraintes bornent le cadre dans lequel les solutions sont autorisées. Pour les phases créatives, des contraintes sobres et pertinentes aident davantage que des catalogues d’exigences complets. L’ordre compte : d’abord la forme et la direction, puis les détails.

Combien de contexte donner aux agents ?

Le contexte est un budget d’attention limité, pas un réservoir à remplir. Commencez avec la quantité minimale hautement pertinente et n’étendez qu’à bon escient. Des prompts longs et flous réduisent le focus et la conformité, surtout pour les instructions placées tard. Mesurez l’impact, pas le volume : de courts tokens précis battent le texte intégral.

Puis‑je utiliser des exemples sans favoriser la fixation ?

Oui, mais avec parcimonie et plutôt comme contre‑exemples ou en contraste. Des modèles forts trop tôt rétrécissent l’espace de recherche et ancrent les premières solutions. N’introduisez des exemples qu’après une phase initiale de divergence, ou marquez explicitement ce qu’il faut éviter. Ils servent alors de repères, pas de gabarits.

Qu’est‑ce que cela change pour les spécifications et les feuilles de route ?

Formalisez les exigences après le choix de la forme. En exécution, garde‑fous et règles de détail sont utiles ; en exploration, ils freinent. Distinguez explicitement la divergence créative de la convergence qui suit. Gardez des feuilles de route multi‑modales : explorer, puis spécifier, puis livrer.

Comment détecter tôt si mes agents « se figent » ?

Prévoyez un premier passage sans contexte et comparez l’étendue, la variance et l’originalité. Si la diversité chute fortement ou si des hypothèses précoces se répètent, la fixation est probable. Surveillez aussi l’allongement des temps d’attente avec beaucoup de contexte pré‑chargé et l’absence de retours à des alternatives antérieures. N’introduisez des signaux perturbateurs que si l’étroitesse vient d’un savoir implicite, pas d’instructions strictes.

Au fond, c’est la même question qu’en l’absence d’agents. Qui, dans votre processus, a encore le droit de proposer quelque chose qui n’est pas écrit dans le brief ?