Build, buy ou partner pour l'IA dans le secteur public

Le système de détermination d'éligibilité d'une agence Medicaid d'un État signale un foyer comme non éligible aux prestations. Le foyer fait appel. Il faut onze mois pour trancher, parce que le modèle sous-jacent a été construit par un fournisseur qui n'existe plus sous la même forme, que le contrat ne comporte aucune clause de séquestre du code source, et que personne dans les effectifs ne peut expliquer comment le modèle pondérait la volatilité des revenus. Ce n'est pas un cas d'école. C'est le risque structurel inscrit dans la décision « buy » lorsqu'elle est prise sans réfléchir à ce qui se passe en année quatre d'un contrat de cinq ans.

Cette leçon déroule la décision build, buy, partner en utilisant ce scénario Medicaid comme fil conducteur, parce que les moteurs d'éligibilité comptent parmi les déploiements d'IA (ou apparentés à l'IA) les plus courants dans les administrations des États américains.

Les trois voies, définies

Build : l'équipe data science de l'agence (ou une unité IT centrale de l'État, comme un Department of Technology) développe et détient le modèle en interne.

Buy : l'agence achète un produit commercial sur étagère ou configurable auprès d'un fournisseur GovTech (une société spécialisée dans les logiciels destinés au secteur public, par exemple la practice secteur public de Deloitte, Maximus, ou des acteurs spécialisés plus petits comme Nava PBC).

Partner : l'agence co-développe avec un laboratoire universitaire, un centre de recherche financé par l'État fédéral ou une association de civic tech (par exemple Code for America), souvent avec une IP partagée et un risque opérationnel partagé.

Aucune de ces voies n'est intrinsèquement supérieure. Le bon choix dépend de trois variables : la vitesse à laquelle vous en avez besoin, le niveau de contrôle nécessaire sur la logique, et votre exposition au vendor lock-in (situation de dépendance aux systèmes propriétaires d'un fournisseur telle que les coûts de sortie deviennent prohibitifs).

Pourquoi les cycles d'achat comptent plus que le modèle lui-même

La plupart des échecs de l'IA dans le secteur public sont des échecs d'achat, pas des échecs d'algorithme.

Un cycle d'achat typique d'un État américain pour un système comme un moteur d'éligibilité Medicaid dure de 18 à 36 mois entre le RFP (Request for Proposal, le document formel de consultation) et la mise en production, selon les estimations courantes du secteur GovTech. L'achat fédéral sous le FAR (Federal Acquisition Regulation) peut être encore plus long. Ce seul calendrier disqualifie le « buy » pour toute agence confrontée à une obligation urgente, par exemple une nouvelle exigence de reporting fédéral avec une échéance à six mois.

Le build contourne le cycle du RFP mais se heurte à une autre horloge : le recrutement. Les salaires data science dans les administrations d'État accusent typiquement un retard de 20 à 40 % sur le privé (estimation de marché approximative), si bien que les agences ont souvent besoin de 6 à 12 mois rien que pour constituer une équipe interne compétente, avant d'écrire la moindre ligne de code de modèle.

Les modèles partner peuvent avancer plus vite sur la construction technique (un laboratoire universitaire peut déjà disposer d'un prototype fonctionnel) mais sont souvent plus lents sur les accords de partage de données, puisque les MOU (Memoranda of Understanding) avec les universités publiques passent par leur propre revue juridique, et que HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation. (Health Insurance Portability and Accountability Act) ou les lois de confidentialité de l'État déterminent quelles données Medicaid peuvent seulement quitter les serveurs de l'agence.

Règle empirique : si l'échéance est réglementaire et fixe, buy ou partner avec une entité déjà titulaire d'une autorisation FedRAMP ou StateRAMP (les programmes de certification de sécurité cloud fédéral/État qui préqualifient les fournisseurs pour le traitement de données publiques). Si l'échéance est souple et que la logique est au cœur de votre mission, build.

Vendor lock-in : le risque qui apparaît après la fin du contrat

Le vendor lock-in dans l'IA publique prend généralement trois formes :

1. Lock-in des données : la plateforme du fournisseur stocke les données d'éligibilité dans un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → propriétaire difficilement exportable.
2. Lock-in du modèle : la logique de décision est une boîte noire, et le contrat n'impose ni documentation, ni artefacts d'explicabilité, ni séquestre du code source.
3. Lock-in des compétences : seuls les salariés du fournisseur comprennent le système, donc l'agence ne peut ni l'auditer ni le modifier de façon indépendante, et changer de fournisseur revient à repartir de zéro.

Pour un moteur d'éligibilité Medicaid, le lock-in est dangereux parce que ces systèmes prennent des décisions ayant des implications en matière de procédure régulière. Sous l'Administrative Procedure Act et ses équivalents au niveau des États, un bénéficiaire à qui la couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète → est refusée a le droit de comprendre et de contester le fondement de ce refus. Si votre modèle est une boîte noire non documentée appartenant à un fournisseur, vous ne pouvez pas produire cette explication à la demande. Cela a déjà donné lieu à des contentieux : l'utilisation par l'Arkansas d'un outil automatisé pour réduire les heures d'aide à domicile de bénéficiaires Medicaid handicapés a été contestée avec succès devant les tribunaux au milieu des années 2010, en partie parce que la méthodologie n'avait pas été suffisamment divulguée. L'Electronic Privacy Information Center (EPIC) tient un suivi public des affaires de responsabilité algorithmique dans les systèmes de prestations sociales, à consulter par quiconque évalue ce type de déploiements.

Clauses contractuelles qui réduisent le risque de lock-in, quelle que soit la voie build/buy/partner :

• Séquestre du code source et des artefacts de modèle (un tiers neutre en conserve une copie, restituée si le fournisseur défaille ou si le contrat prend fin)
• Exigences de portabilité des données dans des formats ouverts (CSV, JSON, pas des binaires propriétaires)
• Exigences d'explicabilité : le fournisseur doit produire une justification en langage clair pour toute décision défavorable
• Clauses de droit d'audit permettant une revue technique indépendante

Un framework de décision simple

Pour le cas Medicaid : la détermination d'éligibilité est à enjeu élevé, exposée au contentieux, et au cœur de la mission de l'agence. Cela plaide pour un build ou un modèle partner étroitement encadré contractuellement, pas pour un buy en boîte noire, même si le buy est plus rapide. Une voie médiane pragmatique que de nombreux États empruntent effectivement : acheter la plateforme de workflow et de gestion des dossiers d'un fournisseur (risque juridique faible, prestation banalisée) tout en construisant ou co-développant la logique de scoring d'éligibilité proprement dite en interne ou avec un laboratoire universitaire, ce qui maintient auditable le composant le plus sensible.

À quoi ressemble vraiment le « partner » en pratique

S'associer à un laboratoire universitaire, ce n'est pas de la R&D gratuite. Cela s'accompagne de ses propres frictions : les calendriers académiques ne coïncident pas avec les exercices budgétaires publics, les incitations à la publication (les chercheurs veulent publier leurs résultats) peuvent entrer en conflit avec les exigences de confidentialité des données, et la propriété de l'IP doit être négociée explicitement avant le démarrage du projet, pas après.

Cela dit, plusieurs États américains ont utilisé avec succès des partenariats universitaires pour des problèmes à enjeu plus faible et à contenu innovant plus élevé, comme prévoir les pics d'inscription à Medicaid ou détecter des schémas de fraude dans les données de remboursement, où le coût d'une prédiction erronée est une inefficacité opérationnelle et non une violation de procédure régulière. C'est le bon profil de risque pour un partenariat : expérimental, pas décisionnel.

Une manière simple de quantifier l'arbitrage : estimer le coût total de possession (TCO) sur un horizon de cinq ans, pas seulement les licences de la première année.

Buy scenario (illustrative, not a real quote):
Year 1 licensing + implementation: $2.0M
Years 2-5 licensing (annual):      $0.6M x 4 = $2.4M
Vendor switching cost (est. if locked in): $1.5M
5-year TCO: ~$5.9M

Build scenario (illustrative):
Team of 4 FTEs x $150K avg loaded cost x 5 years: $3.0M
Infrastructure (cloud, security review): $0.4M
5-year TCO: ~$3.4M, but with 12-18mo delay before go-live

Ce calcul est illustratif, pas un benchmark, les chiffres réels varient énormément selon l'État et le fournisseur. L'intérêt de l'exercice est procédural : obliger les équipes achats à valoriser les coûts de sortie et les coûts de retard, pas seulement le prix affiché.

🎬 [VIDEO: "How Governments Buy Software (and Why It's So Hard)" - youtube.com/@codeforamerica - L'explication de Code for America sur les frictions d'achat dans le secteur public et leur effet sur l'adoption technologique, contexte utile pour comprendre pourquoi les cycles de buy s'allongent]

Points clés

• Ajustez la décision aux enjeux : build ou modèle partner strictement encadré pour la logique cœur de mission fortement exposée au contentieux (comme la détermination d'éligibilité) ; buy pour les tâches de workflow banalisées et à risque faible.
• Les calendriers d'achat (souvent 18-36 mois pour les RFP d'États américains) constituent fréquemment le vrai goulot d'étranglement, pas la performance du modèle ; la pression sur les délais doit donc peser autant que la capacité technique dans le choix build/buy/partner.
• Le vendor lock-in a trois variantes (données, modèle, compétences) ; couvrez-les toutes les trois contractuellement avec séquestre du code source, clauses de portabilité des données et explicabilité obligatoire, quelle que soit la voie retenue.
• Le partenariat avec les universités fonctionne le mieux sur des problèmes exploratoires et non décisionnels (prévision, détection de schémas de fraude), pas sur des décisions ayant des conséquences directes en matière de procédure régulière.
• Calculez toujours le coût total de possession sur un horizon de 5 ans, coûts de sortie estimés inclus, avant de comparer les devis de buy aux estimations de build ; le prix de la première année seul est trompeur.