Le cahier des charges a déjà choisi l'architecture : ce que l'appel d'offres décide avant l'architecte

L’architecte est invité au lancement du projet. Le marché est notifié, le contrat est signé, les équipes sont constituées. On lui présente le périmètre : trois lots, trois titulaires, une date de mise en service annoncée au comité de direction, un forfait par lot. On lui demande de « garantir la cohérence de l’ensemble ».

Il découvre en quelques jours que la frontière entre le lot 1 et le lot 2 passe au milieu du référentiel client. Que les exigences ont été rédigées comme une liste de fonctionnalités reprises de l’existant, ce qui signifie que la solution retenue devra reproduire des règles dont plus personne ne connaît la raison. Que le modèle contractuel au forfait rend chaque apprentissage du projet coûteux à intégrer. Et que le fournisseur a été choisi sur une grille où le prix d’acquisition pesait lourd et la capacité d’intégration presque rien.

Aucune de ces décisions n’a été prise contre lui. Elles ont été prises sans lui, neuf mois plus tôt, dans un document qu’il n’a jamais vu, rédigé par des personnes compétentes qui faisaient exactement leur travail : cadrer un besoin, sécuriser une mise en concurrence, protéger l’organisation juridiquement.

C’est la situation ordinaire, et elle repose sur un malentendu de séquence. La consultation n’est pas l’étape administrative qui précède l’architecture : c’est le moment où une grande partie de l’architecture se décide, par des acteurs qui ne savent pas qu’ils la décident, dans un vocabulaire qui ne la nomme pas. Ce qui est signé n’est pas seulement un prix et un périmètre. C’est un ensemble de contraintes de conception, une répartition des responsabilités entre systèmes, et une liste — invisible — d’options désormais fermées.

Pourquoi la consultation échappe à l’architecture

Trois propriétés structurelles expliquent le phénomène, et il vaut mieux les regarder que s’en plaindre.

Le dossier de consultation appartient à un autre processus. Il a son calendrier, ses instances, son vocabulaire et ses obligations. Il est instruit par les achats, le juridique, le métier commanditaire, parfois une assistance à maîtrise d’ouvrage. Rien dans ce circuit ne comporte de case « conséquences d’architecture », et rien n’oblige à en faire apparaître une. L’architecture n’est pas écartée par décision : elle est simplement hors périmètre du formulaire.

Il faut écrire le plus précisément au moment où l’on sait le moins. C’est le paradoxe propre à l’achat. Une consultation exige un niveau de détail contractuel avant toute conception, donc avant d’avoir instruit les questions qui feront le coût réel : l’état des données à reprendre, le comportement des interfaces existantes, les écarts entre les règles affichées et les règles appliquées. La précision réclamée par le contrat ne correspond pas à la connaissance disponible, et l’écart est comblé par ce qui est accessible : la description de l’existant.

L’irréversibilité change de nature à la signature. Avant, une option se discute. Après, elle a un prix, un porteur et une procédure. L’architecte qui arrive ensuite ne travaille plus sur des choix mais sur des contreparties : chaque correction devient un avenant, c’est-à-dire un sujet où le fournisseur a intérêt à ce que le périmètre initial fasse foi. Ce n’est pas de la mauvaise volonté, c’est la mécanique normale d’un engagement ferme.

La conséquence pratique est simple, et elle ne demande aucune réorganisation : l’architecture doit être présente à la rédaction, pas à la notification. Encore faut-il savoir ce qu’on y cherche.

Les décisions d’architecture qui se prennent sans être nommées

Un dossier de consultation contient au moins cinq décisions structurantes. Aucune ne se présente comme telle.

Le découpage en lots dessine les frontières du système. Un allotissement s’instruit pour de bonnes raisons : élargir la concurrence, éviter la dépendance à un titulaire unique, rendre le marché accessible à des acteurs de taille différente. Dans les achats publics, une partie de ces règles est d’ailleurs imposée. Mais une frontière de lot ne reste jamais contractuelle : elle devient une frontière d’intégration, donc une interface, un contrat d’échange, un point de rupture opérationnel et une zone de discussion sur les responsabilités le jour d’un incident. Un allotissement qui coupe au milieu d’un objet métier — le client d’un côté, son contrat de l’autre, sans que la propriété de la donnée soit tranchée — crée une coexistence permanente que personne n’a conçue. La question à poser n’est pas « faut-il allotir ? », mais « où le coût d’intégration de cette découpe est-il le plus faible ? », et cette question est un exercice d’architecture.

La forme des exigences décide de la forme des réponses. Une exigence rédigée comme une liste de fonctionnalités appelle une réponse qui coche, et une comparaison qui porte sur des tableaux de conformité plutôt que sur des architectures. Le glissement le plus coûteux est plus subtil : lorsque l’exigence est écrite en décrivant le fonctionnement actuel — « le système devra permettre de saisir, dans cet ordre, les mêmes champs » — l’organisation achète son passé au prix du neuf. Elle finance la reconduction de règles qu’elle n’a pas réexaminées, et elle transforme des habitudes en obligations contractuelles. Formuler en capacités et en résultats attendus n’est pas une élégance de rédaction : c’est ce qui laisse au fournisseur la possibilité de proposer une manière de faire différente, et à l’organisation la possibilité de l’accepter.

Le modèle contractuel fixe la tolérance au changement. Un forfait sur un besoin stable et bien connu est un excellent outil. Le même forfait sur un besoin incertain produit un effet prévisible : chaque chose apprise en cours de route devient un avenant, donc une négociation, donc un conflit ; et l’intérêt du titulaire devient de livrer le périmètre littéral plutôt que le résultat utile. Les formes plus souples déplacent la difficulté sans la supprimer : elles supposent une capacité de pilotage interne réelle, c’est-à-dire des personnes disponibles pour arbitrer en continu. Aucune forme n’est supérieure. Ce qui compte, c’est que le choix soit ajusté au niveau d’incertitude — et l’évaluation de cette incertitude est un jugement d’architecture, pas une préférence contractuelle.

Les critères de choix sont le véritable cahier des charges. Une exigence non pondérée n’est pas une exigence : c’est un souhait. Tout ce qui compte réellement pour la suite — la qualité des interfaces, la documentation du modèle de données, les conditions de sortie, la capacité à faire évoluer le paramétrage sans le fournisseur — disparaît si la grille de dépouillement n’en tient pas compte. À l’inverse, une pondération dominée par le prix d’acquisition sélectionne mécaniquement les réponses qui reportent les coûts au-delà de la période évaluée. L’organisation obtient exactement ce qu’elle a pondéré, et elle l’obtient toujours.

Le calendrier annoncé élimine des options avant tout examen. Une date de mise en service communiquée avant la conception n’est pas une contrainte de planning : c’est un filtre d’architecture. Elle écarte d’emblée les trajectoires qui supposent une phase de coexistence, une reprise de données progressive ou un découplage préalable, et elle fait de la bascule unique l’option par défaut — non parce qu’elle a été jugée préférable, mais parce qu’elle est la seule qui tienne dans le délai affiché.

Ce qu’il faut écrire, et qu’on n’écrit presque jamais

Une consultation ne peut pas tout prévoir, et il serait malhonnête de le prétendre. En revanche, un petit nombre de clauses décide de ce que l’organisation pourra encore faire dans cinq ans. Elles ont un point commun : elles portent toutes sur l’après.

La propriété des données, exprimée en mécanismes et non en principes. Tout le monde signe que les données appartiennent au client ; cette phrase ne protège de rien. Ce qui protège tient à quatre précisions : sous quel format les données sont restituables, selon quel modèle documenté, par quel mécanisme accessible sans outil propriétaire, et à quelle fréquence ce mécanisme est exercé. Une restitution qui n’a jamais été réalisée pendant la vie du contrat sera découverte au pire moment, c’est-à-dire au moment où la relation se dégrade.

Les interfaces traitées comme des contrats. Il ne suffit pas d’exiger « des API ». Une interface utile est spécifiée, versionnée, assortie d’une règle de compatibilité et d’un préavis en cas d’évolution incompatible. La clause qui manque presque toujours est celle qui désigne qui supporte le coût d’adaptation lorsque le fournisseur fait évoluer son interface pour ses propres raisons. En son absence, la réponse par défaut est : l’acheteur, indéfiniment.

Les conditions de sortie, et leur épreuve. La réversibilité doit décrire ce qui est restitué, dans quel délai, à quel prix et avec quel accompagnement. Surtout, elle doit être exercée au moins une fois hors situation de crise. Une clause de réversibilité jamais éprouvée n’est pas une garantie, c’est une intention rédigée au moment où les deux parties étaient d’accord.

Les exigences non fonctionnelles rattachées aux capacités métier qu’elles servent. Formulées globalement, elles produisent l’un des deux travers : elles disparaissent, ou elles sont fixées au niveau le plus exigeant pour l’ensemble du périmètre — et payées à ce niveau partout, y compris là où rien ne le justifie. Rattacher chaque exigence de disponibilité, de temps de reprise ou de conservation à la capacité métier concernée transforme une liste déclarative en un ensemble d’engagements finançables.

Les environnements, les données de test et l’accès aux traces. Ce sujet paraît trop opérationnel pour figurer dans une consultation. Il décide pourtant de la capacité à recetter sérieusement, à préparer une reprise de données et à diagnostiquer un incident en production sans dépendre du fournisseur pour chaque question. Ce qui n’est pas prévu au contrat sera facturé au coup par coup ou refusé poliment.

Le régime d’évolution après la mise en service. Un contrat qui décrit finement la construction et reste muet sur la suite laisse l’organisation sans prise là où elle passera l’essentiel du cycle de vie. Il faut y lire : comment une demande d’évolution est instruite, ce qu’elle coûte, qui décide, et ce que l’organisation peut modifier elle-même sans intervention du titulaire. Cette dernière clause est la plus déterminante pour son autonomie future.

Évaluer une réponse sur ce qu’elle rend possible

Le dépouillement est le second moment où l’architecture est décidée sans être nommée. Comparer des tableaux de conformité renseigne sur la capacité des candidats à remplir des tableaux. Trois questions apportent davantage.

Qu’est-ce que cette réponse rend difficile plus tard ? Toute solution ferme des portes ; le sujet n’est pas de l’éviter mais de savoir lesquelles. Une réponse qui suppose que l’organisation adopte le modèle de données du produit n’est pas disqualifiée pour autant — elle peut être le bon choix — mais elle doit être évaluée en sachant ce qu’elle implique sur les échanges, la restitution et les évolutions futures.

Où se logent les dépendances ? Il faut chercher les endroits où la connaissance devient inaccessible : un paramétrage exprimé dans un langage propriétaire, une logique métier enfouie dans des scripts non documentés, un modèle de données que seul le titulaire sait lire. Une dépendance technique se contourne ; une dépendance de connaissance se paie chaque année.

Que se passe-t-il si ce produit change de stratégie ? Un éditeur peut être racheté, une gamme abandonnée, un modèle de licence revu. La question n’est pas de prédire ces événements, mais de savoir ce qu’ils coûteraient — ce qui revient à évaluer la clause de sortie non pas sur sa rédaction, mais sur sa faisabilité réelle.

Une pratique change la qualité du dépouillement plus que toutes les grilles : demander aux candidats de traiter un cas concret plutôt que de déclarer une conformité. Décrire l’interface qu’ils devront construire avec un système existant nommé, expliquer comment ils reprendraient un jeu de données réel et imparfait, dire ce qu’ils feraient d’une règle de gestion contradictoire. Les écarts entre candidats apparaissent immédiatement, et ils portent sur ce qui comptera.

Il faut néanmoins rester lucide sur la portée de l’exercice. Un contrat ne produit pas une bonne architecture ; il rend visibles, au moment du choix, des conséquences qui apparaîtraient sinon deux ans plus tard. C’est une fonction modeste et considérable : la plupart des décisions coûteuses ne sont pas des décisions contestées, ce sont des décisions prises sans que quiconque ait vu ce qu’elles engageaient.

Ce que l’architecture doit tenir

Le rôle de l’architecture dans une consultation n’est pas de rédiger le dossier, ni de superviser les achats. Il est de rendre explicites les décisions d’architecture qui s’y trouvent déjà.

Cela suppose d’intervenir à la rédaction et non à la notification, ce qui est moins une question d’organigramme que de moment : dès que le périmètre et l’allotissement sont en discussion, la fenêtre est ouverte ; à la publication, elle est fermée.

De produire une note d’architecture courte qui accompagne la consultation — frontières du système, objets métier concernés, système de référence pour chacun, interfaces attendues, contraintes non négociables. Quelques pages qui disent ce qui ne se négocie pas valent mieux qu’un dossier technique que personne ne lira.

De faire examiner l’allotissement au regard de son coût d’intégration, en formulant la question dans les termes des achats : chaque frontière de lot est une interface à spécifier, à financer et à exploiter, et cela se compare à l’avantage attendu de la mise en concurrence.

De participer à la pondération des critères, qui est le levier le plus efficace et le plus négligé. Une exigence d’architecture qui ne figure pas dans la grille de dépouillement n’existe pas, quelle que soit la qualité avec laquelle elle a été rédigée ailleurs.

Et de tracer ces arbitrages comme des décisions d’architecture, avec leurs alternatives et leurs raisons. Le découpage retenu, le modèle contractuel et la pondération seront questionnés dans trois ans, quand leurs effets se manifesteront ; il est utile que la réponse ne dépende pas de la mémoire des personnes présentes.

La dernière fenêtre où les options sont gratuites

Une consultation est le dernier moment où les options d’architecture ne coûtent rien. Tant que le dossier n’est pas publié, déplacer une frontière, reformuler une exigence ou changer une pondération se fait par une conversation. Après la signature, la même modification a un prix, un délai et un rapport de force.

C’est pourquoi la question à poser avant de publier n’est pas seulement « avons-nous tout exprimé ? ». C’est « qu’est-ce que ce document rend impossible ? » — et si personne autour de la table n’est capable de répondre, c’est que la décision d’architecture a bien été prise, mais que nul ne l’a vue passer.

On n’achète jamais seulement une solution. On achète un ensemble de dépendances, une frontière entre ce qu’on saura faire seul et ce qu’il faudra demander, et un coût de sortie qui deviendra un jour la vraie mesure de la liberté conservée.