8 contrats EVB-IT révisés, 1 standard open source, clauses plus strictes, ce qui change pour tous les achats publics

Huit contrats types EVB-IT ont été révisés par l’IT-Planungsrat, l’instance de coordination entre l’État fédéral allemand et les Länder sur les grands choix numériques. Le message est sans ambiguïté: lors de l’acquisition de nouveaux logiciels, l’open source devient la référence, avec une exigence de mise à disposition du code sur OpenCoDE, la plateforme publique de partage de logiciels. L’information, relayée par les canaux institutionnels allemands, marque un durcissement méthodologique plus qu’un simple ajustement contractuel: la préférence pour le logiciel libre n’est plus un objectif, elle s’inscrit dans la mécanique d’achat.

Le mouvement dépasse le seul débat technique. Il touche à la souveraineté numérique, à la maîtrise budgétaire et à la capacité des administrations à mutualiser leurs développements. Il pose aussi une question de marché: comment les éditeurs propriétaires et les prestataires de services vont-ils se repositionner quand la commande publique, structurée par des contrats types, impose une trajectoire plus ouverte?

Huit contrats EVB-IT révisés pour faire de l’open source la règle

Les EVB-IT (conditions contractuelles complémentaires pour les prestations informatiques) servent de socle aux achats numériques du secteur public allemand. Leur révision par l’IT-Planungsrat n’a rien d’un détail administratif: ces modèles structurent les clauses relatives à la propriété intellectuelle, aux droits d’usage, à la maintenance, aux garanties et aux responsabilités. En réécrivant huit contrats types, l’instance met la doctrine open source par défaut au cur de la commande publique, au moment même où les administrations cherchent à réduire leur dépendance à des solutions fermées.

Le principe annoncé est simple dans sa formulation mais lourd dans ses implications: pour toute nouvelle acquisition logicielle, l’open source devient le standard. Cela ne signifie pas l’interdiction du propriétaire, mais le renversement de la charge de justification. Dans une logique de conformité, la question n’est plus peut-on acheter de l’open source?, mais pourquoi s’en écarter?. Dans les marchés publics, ce basculement change la négociation: il influence les spécifications, la rédaction des lots, la stratégie des candidats et la manière de valoriser la maintenance ou l’intégration.

Cette révision contractuelle s’inscrit dans un contexte européen où les administrations cherchent à industrialiser leurs pratiques de mutualisation. Le logiciel libre facilite la réutilisation inter-organisations, mais seulement si les droits sont clarifiés et si les obligations de publication sont intégrées dès l’achat. Les contrats types jouent ce rôle de standardisation juridique: ils réduisent l’incertitude et limitent la multiplication de clauses sur mesure qui ralentissent les projets.

Sur le plan opérationnel, la montée en puissance de l’open source par défaut implique un effort de gouvernance: choix de licences, politique de contribution, gestion des dépendances, suivi des vulnérabilités. La commande publique ne peut plus se contenter d’acheter un produit; elle doit acheter une capacité à maintenir et à faire évoluer un code partagé. La révision des EVB-IT vise précisément à aligner les incitations contractuelles avec cette réalité, en cadrant la publication et la réutilisation comme des exigences de base.

OpenCoDE devient un passage obligé pour publier le code financé par l’argent public

La mise à disposition sur OpenCoDE transforme une intention politique en exigence vérifiable. Une plateforme commune permet de centraliser les dépôts, de documenter les projets, de tracer les versions, et de faciliter la réutilisation par d’autres administrations. Sans un lieu de publication identifié, l’open source peut rester théorique: un code libéré mais introuvable, mal documenté ou publié trop tard ne produit pas de mutualisation réelle.

Le choix d’OpenCoDE comme point d’ancrage répond aussi à une logique de conformité et d’auditabilité. Une administration qui finance un développement peut démontrer, dépôt à l’appui, que le code est bien publié selon les termes contractuels. Pour les prestataires, la règle clarifie le livrable: au-delà du binaire et de la documentation, le dépôt devient un élément contractualisé, avec son historique, ses tickets, ses contributions. Le contrôle n’est plus seulement déclaratif.

Cette centralisation pose aussi des questions d’architecture de gouvernance. Publier sur une plateforme commune ne suffit pas: il faut définir qui valide les contributions, qui arbitre les évolutions, et comment se répartissent les responsabilités en cas de faille. L’open source ne supprime pas le risque; il le rend plus visible et plus collectif. En contrepartie, il offre un mécanisme de correction plus transparent, à condition que les équipes aient les moyens de traiter les alertes et d’opérer des mises à jour rapides.

OpenCoDE sert enfin de levier de standardisation des pratiques internes: règles de nommage, exigences de documentation, procédures de revue de code, automatisation des tests. Dans une administration, ces disciplines sont souvent hétérogènes d’un ministère à l’autre. Une plateforme commune, adossée à des contrats types, pousse vers des méthodes plus homogènes. L’enjeu est de passer d’une juxtaposition de projets à un portefeuille réutilisable, où chaque nouveau développement enrichit un patrimoine logiciel partagé.

Achats publics: la bascule du produit vers les services et la maintenance

Quand l’open source devient le standard, la valeur se déplace. Le cur économique ne réside plus dans la vente de licences, mais dans les services: intégration, adaptation, hébergement, support, formation, cybersécurité, et maintenance évolutive. Pour une partie du marché, c’est une opportunité: les entreprises de services numériques, les intégrateurs et les acteurs spécialisés dans l’open source peuvent proposer des offres modulaires, parfois plus compétitives, centrées sur la qualité d’exécution et la réactivité.

Pour les éditeurs propriétaires, le changement est plus délicat. Certains peuvent répondre par des modèles hybrides: ouverture partielle, extension propriétaire, ou bascule vers des offres open core. Mais la commande publique, lorsqu’elle inscrit l’ouverture dans ses contrats types, réduit l’espace des compromis. La négociation se déplace vers des garanties de sécurité, des engagements de niveau de service, et des clauses de réversibilité. Le point critique devient la capacité à sortir d’une solution sans coût prohibitif, ce qui est l’un des arguments majeurs en faveur de l’open source.

Sur le plan budgétaire, l’open source ne signifie pas gratuit. Il réduit certains coûts, notamment ceux liés aux licences et à la dépendance à un éditeur unique, mais il peut augmenter les dépenses de maintenance et d’ingénierie si l’administration ne dispose pas d’équipes capables de piloter l’écosystème. La rationalité économique dépend du volume de réutilisation: plus un logiciel est mutualisé, plus le coût unitaire baisse. À l’inverse, un projet isolé, publié sans communauté, peut devenir un actif coûteux à entretenir.

La révision des EVB-IT vise à sécuriser ce modèle économique par le droit. En cadrant la publication et les droits d’usage, l’administration se donne les moyens de remettre en concurrence la maintenance et l’évolution. C’est un point central: l’open source n’a d’effet sur les prix que si l’acheteur public peut changer de prestataire sans réécrire le logiciel. Le contrat devient alors un outil de politique industrielle, en favorisant un marché de services plutôt qu’un marché de rentes logicielles.

Souveraineté numérique: transparence du code, dépendances et sécurité de la chaîne logicielle

La préférence pour l’open source est souvent présentée comme un choix de souveraineté. La logique est connue: accès au code, audit possible, capacité à corriger sans attendre un fournisseur, et réduction du verrouillage propriétaire. Mais la souveraineté ne se limite pas à l’accès au dépôt. Elle dépend de la maîtrise des dépendances, de la capacité à maintenir dans la durée, et du contrôle de la chaîne de construction et de déploiement.

Les administrations découvrent parfois que l’ouverture du code n’élimine pas les risques importés: bibliothèques tierces, composants transverses, outils de compilation, images de conteneurs. La surface d’attaque se déplace vers la supply chain logicielle. L’approche contractuelle, si elle est bien conçue, peut imposer des exigences de traçabilité: inventaire des composants, documentation des versions, procédures de mise à jour, et gestion des vulnérabilités. Le standard open source ne peut fonctionner que si l’acheteur public formalise ces obligations dans ses cahiers des charges.

La transparence du code améliore aussi la capacité d’audit, mais à une condition: disposer des ressources humaines pour lire, tester et contrôler. Sans compétences internes, l’open source peut devenir une délégation de confiance vers des communautés externes, ce qui ne correspond pas toujours aux besoins d’un système d’information public critique. Le choix de publier sur une plateforme comme OpenCoDE facilite l’organisation d’audits croisés entre administrations, en mutualisant les efforts d’analyse et de correction.

La question de la souveraineté se joue aussi dans la gouvernance des projets. Un logiciel open source peut être dominé par un acteur unique, ou dépendre d’un mainteneur isolé. La commande publique, via des contrats types, peut encourager des modèles de gouvernance plus robustes: documentation obligatoire, bus factor amélioré, et exigences de continuité. Le standard open source n’est pas un aboutissement; c’est un cadre qui oblige à traiter de front la sécurité, la maintenabilité et la résilience.

Ce que la révision des EVB-IT change pour les administrations et les prestataires

Pour les administrations, la conséquence immédiate est procédurale: les équipes achats, juridiques et techniques doivent intégrer le nouveau standard dans leurs pratiques. Cela implique de revoir les modèles de consultation, les critères d’attribution, et la manière d’évaluer les offres. Un projet open source ne se juge pas seulement sur des fonctionnalités; il se juge aussi sur la qualité du dépôt, la clarté de la licence, la stratégie de maintenance, et la capacité du prestataire à travailler en transparence.

Pour les prestataires, la publication sur OpenCoDE modifie la relation au livrable. Le code devient un actif partagé, potentiellement réutilisé par d’autres, ce qui peut réduire les revenus liés à la reproduction de solutions similaires. La différenciation se déplace vers la qualité d’exécution, la compréhension des besoins métier, et la capacité à opérer un service dans la durée. Les entreprises qui ont construit leur modèle sur la vente de solutions fermées devront justifier plus finement les exceptions ou proposer des alternatives.

Le marché peut aussi gagner en fluidité. Si le code est publiquement accessible et réutilisable, une administration peut démarrer plus vite un projet en s’appuyant sur un existant, puis confier l’adaptation à un autre acteur. Cette dynamique favorise la concurrence sur les services. Elle peut aussi réduire les délais, à condition que les administrations investissent dans la documentation et l’industrialisation, sans quoi la réutilisation reste un slogan.

Le choix de standardiser l’open source par contrat pose enfin une question politique: jusqu’où aller dans l’obligation d’ouverture pour des logiciels sensibles? La doctrine par défaut suppose des exceptions, encadrées et motivées, pour des cas où la publication du code augmente le risque opérationnel. La robustesse du dispositif se mesurera à la qualité de ces exceptions, à leur traçabilité, et à la capacité des administrations à ne pas les transformer en échappatoire systématique.

En verrouillant la préférence open source dans huit contrats EVB-IT et en ancrant la publication sur OpenCoDE, l’IT-Planungsrat transforme une orientation en infrastructure de décision, avec un effet mécanique sur les prochains appels d’offres et sur la manière dont le logiciel public sera conçu, maintenu et partagé.