Publié le 17 septembre 2026 à 13:00 · Publication originale
Trois ans plus tard, son fournisseur change le modèle utilisé.
Les performances évoluent.
Qui devait prévenir la ville?
Qui doit tester la nouvelle version?
Quelles données peuvent servir à améliorer le système?
L'administration peut-elle examiner les journaux lorsqu'une décision est contestée?
Ces questions doivent entrer dans le contrat.
L'Union européenne travaille sur ce point avec une communauté d'acheteurs publics consacrée à l'achat d'intelligence artificielle.
En mars 2025, des clauses contractuelles types ont été actualisées pour tenir compte du règlement européen sur l'IA.
Il existe deux versions.
La première concerne les systèmes à haut risque.
Une version allégée peut être adaptée aux autres systèmes.
Depuis juin 2025, l'ensemble existe dans les 24 langues officielles de l'Union.
Ces documents transforment des propriétés techniques en obligations contractuelles: gestion des risques, données, documentation, transparence, contrôle et responsabilités entre fournisseur et acheteur.
Un système d'IA n'est pas nécessairement le même produit pendant toute la durée du contrat.
Son modèle peut changer. Ses données peuvent évoluer. Un fournisseur peut modifier son infrastructure. Une fonction expérimentale peut devenir centrale.
Le contrat doit donc encadrer un objet qui continue à évoluer après son achat.
En juillet 2026, la Commission a installé un groupe d'experts consacré aux contrats d'IA. Il doit notamment travailler sur des clauses horizontales et des orientations destinées aux utilisateurs.
Pour un acheteur, cette évolution change le cahier des charges.
Acheter une performance au jour de la démonstration ne suffit plus.
Il faut aussi contractualiser ce qui pourra changer pendant cinq ans et les informations que le fournisseur devra laisser pour que ces changements restent contrôlables.
ULTRA®
Le contrat d'IA possède une particularité technique rarement visible: il doit définir le périmètre de changement acceptable du système.
On peut figer un "modèle de référence" à la réception puis imposer un test de régression avant toute modification substantielle: nouveau modèle, nouvelle source de données, changement de seuil ou nouvelle chaîne de traitement.
Le fournisseur remet alors un différentiel de version accompagné des résultats sur un corpus d'acceptation conservé par l'acheteur.
Cette séparation est cruciale: si le fournisseur connaît et optimise en permanence le jeu servant à accepter le système, le test finit par mesurer son adaptation au banc d'essai.
Le contrat peut donc prévoir un corpus secret, renouvelé périodiquement, avec seuils de non-régression et droit de retour à la version précédente.
Le logiciel devient contractuellement versionné comme une configuration validée.
Une "mise à jour" peut alors constituer techniquement un nouveau système à accepter.