Acheter du numérique dans le secteur public : le dossier complet

Un ministère qui renouvelle son système de gestion des ressources humaines, une commune qui choisit un logiciel d’état civil, un hôpital qui achète une plateforme de télémédecine : chacune de ces décisions engage l’organisation pour dix ans ou plus, et des sommes importantes. Elle passe par un marché public, avec ses règles de publicité, de mise en concurrence et d’égalité de traitement. Ces règles sont souvent perçues comme un obstacle à un bon achat numérique. Elles le sont moins qu’on ne le croit ; ce qui fait échouer un achat public numérique, ce sont presque toujours des décisions prises avant ou après la procédure.

Ce dossier suit un achat, de l’idée à la fin du contrat, et s’arrête à chaque moment où se prennent les décisions qui comptent. Il s’appuie sur le cadre européen, mais ses principes valent pour la plupart des systèmes d’achat public, y compris les projets financés par des bailleurs internationaux.

Pourquoi les achats numériques sont différents

Acheter des ordinateurs ressemble à n’importe quel achat de fournitures. Acheter un système d’information, non. Trois caractéristiques compliquent l’exercice.

Le besoin n’est jamais entièrement connu au départ. Les utilisateurs découvrent ce qu’ils veulent en voyant les premières versions. Les réglementations changent pendant le projet. Un cahier des charges exhaustif est, au mieux, une hypothèse.

Le coût principal n’est pas le prix d’achat. Licences ou abonnements, hébergement, maintenance, évolutions, formation, exploitation, puis sortie : le coût complet sur la durée de vie dépasse souvent de beaucoup le prix de la première commande.

La dépendance s’installe silencieusement. Formats de données propriétaires, interfaces non documentées, compétences concentrées chez le titulaire : au renouvellement, changer de fournisseur peut devenir si coûteux que la mise en concurrence n’est plus que formelle.

Premier temps : exprimer le besoin, pas la solution

Le défaut le plus courant d’un cahier des charges numérique est de décrire une solution plutôt qu’un besoin. Il liste des écrans, des champs, des boutons, souvent copiés sur le système existant, et fige des choix qui auraient dû être discutés avec le marché.

Une bonne expression du besoin décrit plutôt :

• Le problème à résoudre et les résultats attendus, mesurables si possible
• Les utilisateurs, leurs volumes, leurs contextes d’usage (bureau, terrain, mobilité, faible connectivité)
• Les processus concernés et leurs points de douleur actuels
• Les contraintes : réglementaires, techniques, budgétaires, calendaires
• Les exigences non négociables : sécurité, protection des données, accessibilité, interopérabilité, réversibilité
• Ce qui existe déjà et doit être conservé, relié ou remplacé

Ce travail demande du temps et la participation des utilisateurs réels, pas seulement de leur hiérarchie. Il gagne à s’appuyer sur une observation du travail tel qu’il se fait, plutôt que sur les procédures écrites. C’est aussi le moment de se demander si l’achat est la bonne réponse : une partie des problèmes vient parfois de l’organisation, et aucun logiciel ne la réglera.

Deuxième temps : connaître le marché

Les directives européennes de 2014 autorisent expressément les acheteurs à réaliser des consultations préalables du marché, en vue de préparer la procédure et d’informer les opérateurs économiques. Cette possibilité est sous-utilisée, souvent par crainte de favoriser un fournisseur.

Le risque est réel, mais il se gère : publier un avis de consultation ouvert à tous, rencontrer plusieurs acteurs dans des conditions identiques, tracer les échanges, partager avec tous les candidats les informations communiquées à certains, et ne pas laisser un fournisseur rédiger tout ou partie du cahier des charges. En contrepartie, le gain est considérable : comprendre ce que le marché sait faire, à quel coût, avec quels modèles (logiciel installé, service en ligne, logiciel libre avec prestations), et ajuster le besoin en conséquence.

La méthode compte autant que le principe. Notre guide pour conduire un benchmark de solutions sans parti pris décrit comment comparer des offres sur des critères communs, et notre scénario type sur ce que raconte un benchmark de GED en montre les enseignements.

Troisième temps : choisir la procédure

La directive 2014/24/UE, transposée dans chaque État membre, offre une palette de procédures plus large que la seule procédure ouverte. Le choix dépend de la clarté du besoin et de la nécessité de discuter avec les candidats.

Les seuils européens au-delà desquels ces procédures formalisées s’imposent sont révisés tous les deux ans. Pour 2024 et 2025, ils s’établissent à 143 000 euros hors taxes pour les fournitures et services des autorités gouvernementales centrales, 221 000 euros pour ceux des autres pouvoirs adjudicateurs et 5 538 000 euros pour les travaux. En dessous, les règles nationales s’appliquent, souvent plus souples.

Pour des besoins récurrents (prestations de développement, d’expertise, de maintenance), l’accord-cadre permet de sélectionner un ou plusieurs titulaires pour plusieurs années, puis de passer des commandes au fil des besoins. Les centrales d’achat publiques proposent également des marchés déjà passés, utiles pour les achats standards, à condition de vérifier qu’ils correspondent vraiment au besoin.

Pour les projets financés par des bailleurs internationaux, ce sont les règles de passation du bailleur qui s’appliquent souvent. Celles de la Banque mondiale, par exemple, mettent en avant l’optimisation des ressources et l’adéquation à l’objectif, et permettent aussi des procédures avec négociation ou dialogue.

Quatrième temps : allotir et structurer

Un marché unique qui confie à un seul titulaire le logiciel, son hébergement, sa maintenance, la reprise des données et la formation paraît simple. Il crée une dépendance totale et écarte les entreprises spécialisées. Les directives européennes encouragent d’ailleurs la division en lots, et imposent de justifier le choix de ne pas allotir.

Un allotissement pertinent sépare les fonctions qui peuvent l’être sans créer de difficulté d’intégration excessive : la solution logicielle, l’hébergement, la reprise des données existantes, l’assistance à maîtrise d’ouvrage, la tierce recette. Il faut alors prévoir qui porte la responsabilité de l’ensemble, et les interfaces entre lots. Une assistance à maîtrise d’ouvrage indépendante des fournisseurs de solutions est particulièrement utile : elle conseille l’acheteur sans intérêt dans le choix.

Cinquième temps : rédiger les exigences qui protègent

Certaines clauses ne paraissent pas prioritaires au moment de la rédaction, et se révèlent décisives des années plus tard.

La propriété et le format des données. Les données appartiennent à l’acheteur. Le titulaire doit pouvoir les restituer à tout moment, dans un format ouvert, documenté et exploitable, avec leur structure et leurs métadonnées. Une restitution « dans un format standard » sans plus de précision ne suffit pas.

L’interopérabilité. Des interfaces de programmation documentées, conformes aux standards du domaine lorsqu’ils existent, pour relier la solution aux autres systèmes. Leur usage ne doit pas être facturé comme une option.

La réversibilité. Un plan de réversibilité décrit dès l’offre, chiffré, et testé : comment se passe la sortie, en combien de temps, avec quelle assistance, à quel coût. Sans cette clause, la fin du contrat se négocie en position de faiblesse.

La sécurité et la protection des données. Exigences de sécurité proportionnées, notification des incidents dans des délais fixés, lieu d’hébergement, sous-traitants autorisés, audits. Pour les données sensibles, certaines administrations exigent des qualifications nationales de l’hébergement en nuage, comme SecNumCloud en France. Le contrat doit aussi régler les obligations de sous-traitant au sens du RGPD.

L’accessibilité. La directive 2014/24/UE impose de tenir compte des critères d’accessibilité dans les spécifications techniques des achats destinés à des personnes physiques. Exiger la conformité à la norme EN 301 549 et la vérifier à la recette.

Les licences. Mode de licence (par utilisateur, par usage, forfaitaire), évolution des prix sur la durée, conditions en cas de rachat de l’éditeur. Notre comparatif des modèles de licences logicielles détaille les conséquences de chaque formule.

Le code et la documentation. Pour un développement spécifique, la propriété ou les droits d’utilisation du code produit, sa documentation, et éventuellement sa publication sous licence libre.

On ne négocie bien sa sortie qu’au moment de l’entrée. Après la signature, chaque clause de réversibilité oubliée se paie au prix fixé par le titulaire.

Sixième temps : juger les offres

Le prix le plus bas est rarement le meilleur critère pour un achat numérique. Les directives permettent de retenir l’offre économiquement la plus avantageuse, sur la base du meilleur rapport qualité-prix, voire du coût du cycle de vie.

Quelques pratiques améliorent la qualité du jugement. Raisonner en coût complet sur la durée prévisible d’utilisation, en demandant aux candidats de remplir un modèle commun de coûts (licences, hébergement, maintenance, évolutions, sortie). Demander des démonstrations sur scénarios définis par l’acheteur, à partir de cas réels, plutôt que des présentations commerciales libres. Faire participer des utilisateurs à l’évaluation de l’utilisabilité. Évaluer la méthode et l’équipe proposées, en particulier la continuité des personnes clés. Et rédiger des critères et sous-critères assez précis pour que la notation soit justifiable devant un candidat évincé.

Le choix entre un forfait, une régie ou un centre de services influe aussi sur l’évaluation et le pilotage ; nous l’avons comparé dans forfait, régie ou centre de services.

Le cas des services en ligne

Une part croissante des logiciels est désormais proposée sous forme de services en ligne, hébergés par l’éditeur et facturés par abonnement. Ce modèle simplifie l’installation et la maintenance, mais il modifie les termes de l’achat. Les conditions générales de l’éditeur sont souvent présentées comme non négociables ; les évolutions du logiciel s’imposent à tous les clients ; le prix peut augmenter à chaque renouvellement ; et la sortie suppose de récupérer les données depuis un système que l’acheteur ne contrôle pas.

Quelques exigences restent indispensables, même face à un grand éditeur : localisation et juridiction de l’hébergement, engagements de disponibilité et de restauration, notification des incidents, encadrement des sous-traitants au sens du RGPD, export complet des données à tout moment dans un format documenté, préavis en cas d’évolution substantielle du service ou des prix. Lorsqu’un éditeur refuse toute discussion sur ces points pour un usage critique, c’est une information utile pour le choix.

Septième temps : piloter le contrat

La signature n’est pas la fin de l’achat, c’est le début de sa partie la plus longue. Beaucoup d’échecs viennent d’un acheteur qui, faute de moyens, laisse le titulaire piloter seul.

Un pilotage efficace repose sur quelques éléments. Une équipe côté acheteur, avec un responsable de produit qui connaît le métier et a le pouvoir de décider. Des comités réguliers, avec des indicateurs de service et de qualité définis au contrat. Une recette réelle, avec des utilisateurs et des scénarios, et le courage de refuser une livraison non conforme. Un suivi des écarts et des pénalités appliquées lorsqu’elles sont dues. Et une documentation tenue à jour par le titulaire, vérifiée par l’acheteur.

Pour les projets conduits par itérations, l’accord-cadre à bons de commande fondé sur des unités d’œuvre permet de commander par étapes, d’évaluer la valeur livrée et d’ajuster les priorités sans renégocier le marché. Il suppose une discipline de pilotage plus forte, puisque le périmètre n’est pas figé à l’avance.

Préparer la fin dès le début

Deux à trois ans avant l’échéance d’un marché important, le travail de renouvellement doit commencer : bilan de la solution, évolution du besoin, état du marché, test du plan de réversibilité. Lorsqu’il est lancé six mois avant, il aboutit presque toujours à une reconduction de fait, faute de temps pour organiser une transition.

Tracer les décisions tout au long du contrat facilite aussi ce moment : qui a validé quelle évolution, quelle dérogation, quel avenant, sur quelle base. Ces traces servent aux contrôles, aux contentieux éventuels, et à la mémoire d’une organisation dont les équipes changent.

Acheter de l’innovation et ouvrir le marché

Les règles de la commande publique sont souvent accusées de favoriser les grands fournisseurs installés. Une partie de ce reproche tient moins aux règles qu’à leur usage : des marchés uniques et volumineux, des exigences de références et de chiffre d’affaires disproportionnées, des délais de réponse courts. Plusieurs leviers permettent d’ouvrir l’accès aux petites entreprises et aux solutions innovantes.

L’allotissement, déjà évoqué, en est le premier. Les critères de capacité proportionnés en sont un autre : la directive de 2014 limite le chiffre d’affaires minimal exigé, en principe, au double de la valeur estimée du marché, et permet de tenir compte de capacités apportées par des partenaires ou des sous-traitants. La publication anticipée des projets d’achat, par exemple dans une programmation annuelle, laisse aux entreprises le temps de se préparer et de s’associer.

Pour les besoins qui n’ont pas de réponse sur le marché, le partenariat d’innovation permet de financer une phase de recherche et de développement puis d’acquérir le résultat sans nouvelle mise en concurrence, si les objectifs de performance sont atteints. Les achats avant commercialisation, qui portent sur des services de recherche et de développement en partageant les risques et les bénéfices avec plusieurs entreprises, constituent une autre voie, encouragée par la Commission européenne. Ces formules demandent une ingénierie plus lourde que l’achat d’une solution existante ; elles sont réservées aux besoins réellement nouveaux.

Enfin, la réutilisation entre administrations est souvent la forme d’innovation la plus économique : une solution développée pour une collectivité ou un ministère, publiée sous licence libre avec sa documentation, peut être reprise par d’autres, qui n’achètent plus que l’adaptation et l’exploitation. Plusieurs pays ont créé des catalogues de logiciels publics réutilisables pour faciliter cette démarche.

Récapitulatif pour un acheteur

1. Décrire le besoin avec les utilisateurs, sous forme de résultats et de contraintes plutôt que de fonctionnalités.
2. Consulter le marché de façon ouverte et tracée avant de finaliser le cahier des charges.
3. Choisir la procédure qui correspond au degré de clarté du besoin, sans s’interdire la négociation ou le dialogue.
4. Allotir ce qui peut l’être, et s’entourer d’un conseil indépendant des fournisseurs.
5. Exiger la propriété des données, des formats ouverts, des interfaces documentées et une réversibilité chiffrée.
6. Juger en coût complet, sur des scénarios réels, avec des utilisateurs.
7. Piloter le titulaire avec une équipe dédiée, des indicateurs et une recette exigeante.
8. Préparer le renouvellement plusieurs années avant l’échéance.

Notre expertise neutralité accompagne les acheteurs publics dans ces étapes, sans intérêt dans le choix des solutions. Pour garder la trace datée des décisions prises au fil d’un contrat, notre produit Gouvernance est conçu pour cet usage.

1. Directive 2014/24/UE du Parlement européen et du Conseil du 26 février 2014 sur la passation des marchés publics (notamment articles 26 à 32, 40, 42, 46 et 67).
2. Règlement délégué (UE) 2023/2495 de la Commission relatif aux seuils applicables aux procédures de passation des marchés.
3. Banque mondiale, règlement de passation des marchés pour les emprunteurs sollicitant le financement de projets d’investissement.
4. Norme EN 301 549, exigences d’accessibilité pour les produits et services TIC.

Questions fréquentes

Faut-il tout spécifier dans le cahier des charges ?

Non. Un cahier des charges qui décrit la solution dans le détail fige des choix avant d'avoir rencontré le marché et rend l'adaptation difficile. Il vaut mieux décrire précisément le besoin, les résultats attendus, les contraintes et les exigences non négociables (sécurité, accessibilité, interopérabilité, réversibilité), et laisser les candidats proposer leurs solutions.

Peut-on rencontrer des fournisseurs avant de lancer un marché ?

Oui. Les directives européennes autorisent expressément les consultations préalables du marché, à condition qu'elles ne faussent pas la concurrence : informations partagées avec tous les candidats, traçabilité des échanges, absence d'avantage pour ceux qui ont été consultés.

Comment acheter un projet agile dans un marché public ?

Plusieurs formules le permettent, notamment l'accord-cadre à bons de commande fondé sur des unités d'œuvre (une itération, une équipe pendant une période, un service), combiné à un pilotage par la valeur livrée. La clé est de contractualiser une capacité et une méthode plutôt qu'un périmètre figé.

Les logiciels libres sont-ils compatibles avec les marchés publics ?

Oui. On peut acheter des prestations autour d'un logiciel libre (installation, adaptation, maintenance, hébergement) comme n'importe quel service. On peut aussi exiger, dans un marché de développement, que le code produit soit remis sous une licence libre, ce qui facilite la réutilisation et réduit la dépendance.