Ce que change l'arrêt du CE sur la commande de prestations de conseil.

Vous devez lancer un projet informatique. Le besoin est réel. Le budget existe peut-être. Un prestataire sait déjà présenter une trajectoire, un planning, une équipe et un prix.

La décision n’est pas encore prête.

C’est là que l’arrêt du Conseil d’État du 17 avril 2026 mérite d’être lu autrement. Il ne dit pas seulement qu’un acheteur public peut solliciter plusieurs devis sans faire automatiquement basculer son achat dans un MAPA. Il rappelle surtout une chose utile : la comparaison n’est pas une faute. Elle peut être une méthode.

Encore faut-il comparer le bon objet.

Pour les achats informatiques publics, le sujet n’est pas de demander trois devis pour choisir plus vite un prestataire de développement, d’intégration ou d’AMOA. Le sujet est de pouvoir acheter, en amont, une clarification indépendante avant d’engager un marché lourd.

Une petite mission de cadrage peut éviter un mauvais programme. Une revue critique peut éviter un développement inutile. Un benchmark peut montrer qu’un outil existant répond déjà à l’essentiel du besoin. Une analyse de coût complet peut rendre visible une dépendance que le prix d’entrée ne montre pas.

Le meilleur achat informatique n’est pas toujours celui qui lance le projet. C’est parfois celui qui permet de ne pas le lancer.

Trois devis ne font pas une méthode

L’arrêt du Conseil d’État clarifie une pratique. Lorsque le Code de la commande publique permet de conclure un marché sans publicité ni mise en concurrence préalables, le fait de solliciter plusieurs devis ne suffit pas, à lui seul, à imposer les règles de la procédure adaptée.

Cette précision est utile.

Elle ne crée pas une procédure informelle des “trois devis”. Elle ne permet pas de découper artificiellement un besoin. Elle ne dispense pas l’acheteur de choisir une offre pertinente, de préserver les deniers publics et d’éviter de recourir systématiquement au même opérateur.

Elle ouvre autre chose : une capacité de discernement en amont.

L’acheteur public peut demander plusieurs regards. Il peut tester un prix. Il peut faire préciser une proposition. Il peut comparer des approches. Il peut faire intervenir un tiers indépendant avant que le besoin ne soit capturé par une trajectoire technique déjà écrite.

La vraie question n’est donc pas : combien de devis faut-il demander ?

La vraie question est : que faut-il vérifier avant d’engager l’organisation dans un projet informatique difficile à reprendre ?

Le mauvais réflexe consiste à acheter trop gros, trop tôt

Un besoin métier ne devient pas automatiquement un système d’information à développer.

C’est pourtant un glissement fréquent. Une difficulté opérationnelle apparaît. Une direction cherche un outil. Un prestataire propose une architecture. Une AMOA traduit le besoin. Un marché se prépare. Le projet prend la forme d’un développement spécifique, d’une intégration complexe ou d’un programme pluriannuel.

La décision de départ n’a parfois jamais été examinée.

Le problème venait-il vraiment d’un outil ? Fallait-il simplifier une règle de gestion avant de l’informatiser ? Une application existante pouvait-elle couvrir 70 % du besoin ? Une mutualisation était-elle possible ? Une procédure interne pouvait-elle être modifiée avant d’acheter ? Le coût de maintenance a-t-il été regardé avant le coût de construction ?

Ces questions arrivent souvent trop tard.

Une fois le marché lancé, l’administration doit piloter ce qu’elle a commandé. Elle doit expliquer les retards. Elle doit absorber les avenants. Elle doit maintenir une trajectoire devenue visible politiquement. Elle doit parfois poursuivre un projet qu’elle aurait arrêté si elle avait disposé plus tôt d’une lecture complète du besoin, des options et des dépendances.

Le prix d’un mauvais cadrage n’apparaît pas toujours dans la ligne budgétaire du cadrage. Il apparaît plus tard, dans le coût du programme.

L’asymétrie d’information structure l’achat informatique

Un prestataire ne présente pas spontanément les raisons de ne pas acheter ce qu’il vend.

Ce n’est pas une accusation. C’est un alignement d’intérêts. Un éditeur vend son produit. Un intégrateur vend sa capacité d’intégration. Une ESN vend du temps et des profils. Un cabinet d’AMOA vend une trajectoire de mission.

L’acheteur public, lui, doit défendre une décision. Il doit savoir si le besoin est réel, si l’option proposée est proportionnée, si le prix est cohérent, si les compétences annoncées seront réellement mobilisées, si la sortie est possible et si l’organisation pourra reprendre la main.

Ces lectures ne sont pas toujours disponibles au même endroit.

Le risque de sélection adverse commence là. Une entreprise peut très bien maîtriser les codes administratifs de la réponse à marché sans être la mieux placée techniquement. Une autre peut sous-estimer la charge pour être compétitive, puis reconstituer sa marge par des avenants, des extensions, des prestations complémentaires ou des dépendances d’exploitation.

Le risque d’aléa moral commence après la signature. Les profils annoncés ne sont pas toujours ceux qui font le travail. Les livrables peuvent rassurer sans permettre d’arbitrer. La régie peut durer parce que personne ne sait exactement ce qui permettrait de l’arrêter.

Le devis ne résout pas ces risques s’il ne regarde que le prix.

Il devient utile lorsqu’il force à documenter les hypothèses.

Le coût complet ne se lit pas dans le prix d’entrée

La réponse à la candidature ne vous donne pas le coût complet de votre solution.

Un devis informatique peut être raisonnable au démarrage et coûteux dans la durée. C’est particulièrement vrai pour les prestations liées au cloud, aux outils SaaS, aux ERP, aux CRM, aux plateformes de données et aux briques d’intégration.

Le coût réel comprend rarement une seule ligne. Il comprend les licences, le paramétrage, l’intégration, la reprise de données, la maintenance, le support, la formation, les évolutions, le pilotage interne, les connecteurs, les API, les contraintes de sécurité, les hausses tarifaires, la réversibilité et la migration.

La dépendance se construit souvent par petites décisions.

Un format propriétaire. Une API mal documentée. Une reprise de données facturée tardivement. Une personnalisation excessive. Une compétence rare. Une clause de sortie imprécise. Un contrat cloud facile à signer, mais difficile à quitter.

Le Data Act change une partie de ce rapport de force, notamment pour les services de traitement de données et le changement de fournisseur cloud. Il ne supprime pas le besoin d’examiner la sortie dès l’entrée. Une règle nouvelle ne remplace pas une capacité opérationnelle de migration.

Une clause de réversibilité ne garantit pas une sortie réelle. Il faut savoir quelles données sortent, dans quel format, avec quelle documentation, dans quel délai, avec quelle continuité de service et à quel coût résiduel.

L’acheteur ne doit plus découvrir le coût de sortie au moment où il veut sortir.

Ce que les acheteurs publics peuvent changer dès maintenant

La souplesse validée par le Conseil d’État doit servir à acheter une décision avant d’acheter une trajectoire.

Concrètement, un acheteur public peut utiliser un achat de faible montant pour commander une mission courte et indépendante avant un projet informatique plus lourd.

Cette mission ne doit pas refaire le travail de la DSI, remplacer l’avocat ou écrire tout le cahier des charges. Elle doit répondre à des questions ciblées.

Quel est le besoin réel ?
Quelles règles doivent être simplifiées avant d’être informatisées ?
Quels outils existants couvrent déjà une partie du besoin ?
Quel est le coût complet à trois ou cinq ans ?
Quel risque de dépendance crée chaque option ?
Quels éléments du devis doivent être renégociés ?
Quels coûts sont absents de la première proposition ?
Quels critères permettraient d’arrêter le projet avant qu’il ne devienne irréversible ?

Cette dépense est modeste au regard de ce qu’elle peut éviter.

Dépenser quelques milliers d’euros pour vérifier qu’un développement spécifique n’est pas nécessaire peut être une décision plus rigoureuse que de lancer directement un marché de plusieurs millions. Le gain financier ne vient pas de quelques jours-hommes négociés. Il vient du projet inutile qui n’est pas lancé, du mauvais périmètre qui est réduit, ou de la dépendance qui est évitée avant signature.

Demander un devis de décision, pas seulement un devis de réalisation

Un devis de développement répond à une question : combien coûte la construction de ce que vous demandez ?

Un devis de décision répond à une autre question : faut-il vraiment le construire ?

Cette distinction change l’achat.

Avant un grand marché informatique, l’acheteur peut demander un devis pour une revue indépendante du besoin. Il peut demander un benchmark des outils existants. Il peut demander une analyse de coût complet. Il peut demander une contre-expertise d’un cahier des charges. Il peut demander un examen des dépendances fournisseur. Il peut demander une lecture des conditions de sortie.

Ces prestations doivent produire des livrables courts.

Une note de besoin.
Une grille d’options.
Une estimation de coût complet.
Une liste des risques.
Une analyse des dépendances.
Une recommandation argumentée.
Un verdict : poursuivre, ajuster, différer ou arrêter.

Le livrable n’a pas besoin d’être long pour être utile. Il doit permettre de décider.

C’est aussi là que les indépendants ont une utilité particulière. Celui qui conseille sur le choix ne devrait pas être celui qui vend ensuite la réalisation. Cette séparation ne garantit pas l’absence de biais. Elle réduit au moins le conflit d’intérêts le plus visible.

Une recommandation n’a pas la même valeur lorsque celui qui la formule facture aussi la suite.

Vérifier le prix de marché avant d’accepter le prix public

Un prix présenté à un pouvoir adjudicateur peut intégrer des coûts qui ne sont pas toujours explicités.

Certains sont légitimes : formalisme, délais de paiement, exigences documentaires, sécurité, contraintes de conformité, suivi administratif. D’autres doivent être discutés : surdimensionnement de l’équipe, durée excessive, pilotage disproportionné, frais de coordination flous, charges d’atelier non reliées à un livrable, marges masquées dans des profils mal décrits.

L’acheteur peut aujourd’hui contrevérifier plus facilement.

Il peut comparer avec des marchés existants. Il peut regarder des catalogues de centrales d’achat. Il peut solliciter un indépendant. Il peut utiliser un outil d’IA générative pour préparer ses questions. Il peut demander à un outil de marché de l’aider à décomposer le prix.

L’IA ne prouve pas le juste prix. Elle aide à poser de meilleures questions.

Par exemple, l’acheteur peut prendre un devis reçu et demander :

“Voici une proposition de 38 000 euros HT pour une mission de cadrage d’un projet data de six semaines. Les livrables annoncés sont les suivants. Les profils annoncés sont les suivants. Quels postes doivent être clarifiés ? Quels coûts semblent absents ? Quelles questions poser avant signature ? Quels éléments pourraient révéler une surcotation ou une sous-estimation de charge ?”

La réponse ne doit pas être utilisée comme une expertise définitive. Elle peut servir de grille de vigilance.

Le point important est simple : avant d’accepter un prix, il faut comprendre ce qu’il contient, ce qu’il exclut et ce qu’il rend probable ensuite.

Les questions à poser avant de signer

Un devis informatique doit être interrogé avant d’être accepté.

Voici les questions utiles.

Quel problème précis la prestation résout-elle ?
Quel livrable permettra de vérifier que le travail est fait ?
Quels profils interviendront réellement ?
Combien de jours sont affectés à chaque profil ?
Quelle part du prix correspond au pilotage ?
Quelles hypothèses expliquent la charge ?
Qu’est-ce qui est exclu du périmètre ?
Quels coûts apparaîtront après la mission ?
Une option plus simple a-t-elle été examinée ?
Une option existante a-t-elle été comparée ?
Quel est le coût complet à trois ou cinq ans ?
Quels éléments créent une dépendance fournisseur ?
Comment les données peuvent-elles être exportées ?
Quelle capacité doit rester en interne ?
Qu’est-ce qui permettra d’arrêter ou de recalibrer le projet ?

Ces questions ne ralentissent pas l’achat. Elles évitent de déplacer le coût vers l’exécution.

Ce qu’enbi examine

enbi examine la décision avant l’engagement.

Pour un achat informatique public, cela signifie regarder le besoin, les options existantes, le coût complet, les dépendances, les conditions de sortie, les livrables et les intérêts économiques des prestataires en présence.

enbi ne vend pas l’outil évalué. enbi n’intègre pas la plateforme. enbi ne remplace pas la DSI, l’acheteur ou l’avocat. enbi aide à qualifier la décision avant qu’elle ne devienne difficile à reprendre.

L’intervention peut être courte. Elle doit produire une position utilisable.

Poursuivre.
Ajuster.
Renégocier.
Comparer autrement.
Différer.
Arrêter.

Une décision publique n’a pas besoin d’être spectaculaire. Elle doit être défendable.

Ce que cette analyse change pour une décision

Avant de commander un système d’information, commandez une décision.

Décrivez le besoin. Faites vérifier les options. Exigez le coût complet. Regardez la sortie. Séparez le conseil du vendeur. Documentez les points d’arrêt.

Ce travail ne garantit pas le succès d’un projet. Il rend plus difficile la mauvaise décision automatique.

Demander un sprint de cadrage →