Résumé

  • La VITA avait recensé plus de 850 applications à moderniser et plus de 300 à traiter en urgence, selon les chiffres cités par JLARC.
  • Le projet de rapport recommande une procédure accélérée pour les outils de programmation assistée par IA.
  • La VITA dispose déjà d’une chaîne d’approbation et d’exigences de contrôle du code ; le fast-track doit les adapter au risque réel.

Un inventaire de maintenance donne une mesure. Une procédure d’approbation n’en donne pas encore le délai.

La Virginia Information Technologies Agency (VITA) avait identifié, en août 2025, plus de 850 applications informatiques de l’État à moderniser ; plus de 300 nécessitaient une attention urgente. Le chiffre apparaît dans le projet de rapport de la Joint Legislative Audit and Review Commission, daté du 13 octobre 2026 et encore marqué « Commission draft ». JLARC estime que les assistants de programmation pourraient contribuer à la modernisation si leur usage est encadré. Sa recommandation demande à VITA d’accélérer l’examen des propositions de recours à ces outils et de publier des règles techniques et d’atténuation des risques. Le rapport et son annexe de recommandations ne précisent ni les applications concernées ni la durée actuelle des examens.

Une proposition de code sur un dépôt public et un agent qui peut écrire dans une branche de production n’ont pas le même rayon d’action. Le premier peut aider une équipe à explorer une correction dans un bac à sable. Le second peut toucher des fichiers internes, des données protégées et un service utilisé par le public. Le délai d’examen doit dépendre de ces accès.

La Virginie possède déjà une procédure centrale. La politique EA400 de la VITA, mise à jour en juin 2026, impose l’inscription au registre de l’État pour les systèmes d’IA qu’une agence cherche à développer, mettre en œuvre ou acheter. L’examen passe par le représentant informatique et le responsable de la sécurité de l’agence, puis par la VITA et le CIO du Commonwealth, puis par le secrétaire à l’Administration. Les critères portent notamment sur l’équité, le bénéfice public, la supervision humaine, le risque, les données, les coûts et les garanties du fournisseur. La politique EA400 donne donc un cadre à l’achat et au déploiement ; la question est la place des outils de code dans cette chaîne.

JLARC reproche au dispositif d’appliquer largement les mêmes exigences à des risques différents. L’agence n’a pas publié de méthode commune d’évaluation du risque, alors que les demandes devaient en identifier. Quarante-huit pour cent des agences exécutives qui utilisaient une IA fonctionnelle ont cité le manque de clarté comme contrainte majeure ou modérée. Le projet relève aussi que les règles de la VITA ne traitent pas des agents autonomes ni des protections nécessaires lorsqu’ils accèdent aux systèmes et données de l’État.

Une seule file d’attente peut donc coûter trop cher aux usages simples et rester trop faible face aux outils puissants.

La demande existe déjà dans les administrations. Quatre-vingt-dix-sept pour cent des agences interrogées autorisaient une certaine utilisation d’IA généraliste par leurs employés, souvent avec des restrictions. JLARC estime que 76 % des employés servis par la VITA ont utilisé un outil de ce type pendant un mois donné. Les administrations ont notamment cité l’amélioration du code parmi les usages. Ces chiffres ne montrent pas combien de systèmes du parc se prêtent à l’assistance au code ; ils indiquent que la question ne relève plus d’un futur lointain. La synthèse de JLARC distingue les systèmes d’agence et les outils généralistes.

Il faut aussi séparer l’autorisation d’un outil du contrôle du code qu’il produit. La FAQ de la VITA indique qu’un développeur qualifié doit examiner le code avant son entrée dans une branche, puis que des contrôles de sécurité, fonctionnels et de performance doivent précéder la production. Cette revue protège la version qui sera mise en service. Elle ne désigne pas, à elle seule, les dépôts qu’un assistant peut lire ni le délai de décision de l’État.

JLARC associe précisément l’accélération à des consignes techniques et à la réduction du risque. VITA peut réserver une voie courte aux essais isolés sur du code public ou des données synthétiques. L’accès aux dépôts internes demanderait un propriétaire nommé, des permissions limitées et une trace des changements. Les données sensibles et les écritures autonomes en production exigeraient un examen renforcé, des essais reproductibles et un responsable du retour arrière. C’est une proposition d’organisation, pas une règle déjà adoptée.

Le projet de JLARC ne dit pas combien des 850 applications conviennent à ces outils ni combien de jours une demande met à aboutir. VITA devrait publier ces deux chiffres par niveau d’accès ; ils diraient si la file d’approbation ralentit réellement la modernisation ou si le goulot se situe ailleurs.

Sources : Rapport 621 de JLARC ; recommandations du projet ; politique VITA EA400 ; FAQ de la VITA ; norme EA225.