No. 03 · Technical

Git Insights

Nous avons braqué l'IA sur l'ensemble du parc de code de l'Alberta afin d'en établir la vérité de terrain. Voici comment cela fonctionne et ce que nous y avons découvert.

Comme bien des grandes organisations, l'Alberta utilise GitHub Enterprise comme dépôt de code principal. GitHub offre de puissants outils d'analyse pour le balayage du code grâce à des fonctionnalités comme CodeQL, ainsi que des intégrations avec NPM et Maven pour le balayage des vulnérabilités des dépendances. Les secrets sont automatiquement signalés et bloqués afin de pouvoir être retirés, et notre équipe de cybersécurité dispose d'évaluations bien intégrées. Le problème, c'est que ces vérifications reposent surtout sur des règles déterministes et logiques, de sorte qu'elles présentent un taux élevé de faux positifs, et qu'elles ne disent absolument rien des éléments qui comptent tout autant : l'absence de documentation, de pipelines automatisés de construction et de déploiement, et de tests unitaires automatisés. De plus, il était impossible d'obtenir un bilan de santé global de nos systèmes gouvernementaux. Pour évaluer correctement l'état actuel de notre technologie, il nous fallait regarder plus en profondeur.


## §01 Les données que nous ne pouvions pas voir

Reconstituer le portrait d'ensemble d'une grande organisation peut s'avérer ardu. Dans leur état par défaut, nos principaux systèmes officiels ne pouvaient pas être reliés entre eux. L'information sur les dépendances provenant de GitHub n'alimentait pas notre base de données de gestion des configurations. Cette base de données résidait dans ServiceNow et était tenue à jour manuellement, avec plus de 100 000 entrées couvrant ces applications. Les fiches de nos applications étaient éparpillées entre GitHub, des billets Jira et Confluence, des outils de suivi d'incidents, de la documentation SharePoint et une multitude d'inventaires en feuilles de calcul. Intégrer ces données non structurées était historiquement impossible, car il n'existait aucune clé de liaison pour rattacher un jeu de données au suivant. 

Entrées de la CMDB tenues à jour manuellement 100 000+. Conservées dans ServiceNow, sans aucun flux automatisé depuis GitHub. La structure logique va du ministère au projet ou au programme, puis à l'application et au dépôt, et se déploie ensuite en sprints, en CMDB, en billets et en documentation, sans aucun lien entre eux.

Résultat : aux échelons du sous-ministre et du sous-ministre adjoint, la direction ne pouvait obtenir de réponses utiles à partir des outils habituels, et le personnel peinait à fournir des constats. GitHub lui-même risquait aussi de se transformer en bourbier où des prototypes rapides côtoyaient des systèmes de production sans rien pour les distinguer. Nous ne pouvions affirmer avec confiance ce que nous exploitions, à quel point c'était sain, ni où se trouvait l'exposition réelle. Nous avons donc agi.


## §02 Bâtir un éclaireur

En utilisant Claude Code comme agent de codage, les modèles Opus et Sonnet pour l'analyse, et Google Vertex (désormais Google Agent Platform) comme couche agentique, l'Alberta a bâti un outil appelé **Git Insights**. Il s'agit d'un outil à vocation agentique qui balaie récursivement l'ensemble du parc GitHub. Il fonctionne comme un éclaireur de reconnaissance, inspectant chaque dépôt pour rapporter ce qui s'y trouve réellement. Le code constitue la vérité de terrain.

Lues par les agents en une vingtaine d'heures 466 millions de lignes. Un balayage de l'ensemble du parc qu'aucun mandat de consultants n'aurait pu égaler en temps ni en coût. Un tiers des dépôts n'avait aucune documentation, alors les agents l'ont rédigée, et chaque dépendance a été répertoriée.

Le moment de ce balayage était important. L'Alberta a constaté une hausse marquée du nombre de vulnérabilités connues à travers le parc. Sur nos outils de suivi des bogues, les vulnérabilités augmentent avec un point d'inflexion marqué qui coïncide avec la sortie de Mythos d'Anthropic, des plus récents modèles Opus, et de GPT 5.4 et 5.5 d'OpenAI. La même capacité qui permet à un outil comme Git Insights de lire le parc en profondeur est celle qui permet aux attaquants d'y repérer les failles, un point développé en détail dans le document sur la cybersécurité. Dans les 4 semaines suivant la sortie de Mythos, l'Alberta a conçu ses propres outils et méthodes puissants pour réaliser cette analyse.


## §03 Comment fonctionne Git Insights

Voici ce que fait réellement Git Insights, en termes simples. Il fonctionne sur deux couches. Au sommet, une flotte d'agents parcourt l'ensemble du parc d'un seul coup. À l'intérieur de chaque dépôt de code, chaque agent exécute la même routine fixe. Un moteur de règles procède à un examen de la base de code et signale les motifs reconnus pour une investigation plus poussée, tandis que l'agent d'IA intervient pour réviser et porter un jugement. Tous les constats sont consignés et vérifiables par un humain jusqu'à la ligne de code.

Les agents s'exécutent sur Google Agent Platform. Google a travaillé en étroite collaboration avec l'Alberta pour nous assurer un débit suffisant, portant notre capacité à 25 millions de jetons par minute afin que nous puissions maximiser la vitesse d'analyse. Nous l'avons aussi conçu pour qu'il soit résilient. Si un balayage échoue ou atteint une limite de débit, cette tâche unique patiente et réessaie pendant que les autres se poursuivent, et si l'ensemble du balayage est interrompu, il reprend exactement là où il s'était arrêté. C'est cette résilience qui lui permet de lire 466 millions de lignes à travers des milliers de dépôts en une vingtaine d'heures, en repoussant les limites de notre capacité de traitement.

Une question légitime est de savoir jusqu'où un gouvernement peut se fier à ce que l'IA rapporte. Trois choses la maintiennent honnête. Premièrement, le travail fastidieux et dénombrable, dresser la liste des fichiers et repérer les motifs reconnus comme mauvais, est accompli par du code ordinaire, incapable d'inventer un résultat. Deuxièmement, on ne prend jamais l'IA au mot : lorsqu'elle signale un problème, elle doit nommer le fichier et la ligne exacts, dire à quel point c'est grave et pourquoi, et dire comment le corriger, afin qu'un développeur puisse ouvrir le fichier et confirmer l'affirmation. Troisièmement, elle note chaque dépôt selon la même liste de contrôle fixe, couvrant la sécurité, la qualité du code, l'architecture, la documentation, les tests, la maintenabilité et la santé des bibliothèques dont il dépend, de sorte qu'une note signifie la même chose au millième dépôt qu'au premier. Chaque constat que l'IA rapporte peut être ouvert et vérifié par rapport au code réel. Les constats sont stockés dans une base de données, permettant une méta-analyse par encore d'autres agents exploités par les équipes de cybersécurité et de livraison afin de détecter les tendances et les constats transversaux.

Chaque balayage détecte les vieilles technologies tapies à l'intérieur, comme le COBOL, l'ASP classique et des versions de .NET et de Java sans soutien depuis longtemps, et il infère quel ministère en est propriétaire. Il répertorie chaque dépendance dont un système dépend, ce qui constitue l'inventaire exact que notre base de données de gestion des configurations n'a jamais eu et dont elle peut désormais être alimentée. Il signale les dépôts qui contiennent des renseignements personnels de nature délicate, de sorte qu'un risque pour la vie privée devient visible plutôt qu'enfoui. Et pour les 1 280 dépôts qui n'avaient aucune documentation, l'agent l'a rédigée à partir de ce qu'il venait de lire, tout en validant ou en améliorant le README de chaque autre dépôt. Cela a ramené l'écart à zéro : pour la première fois, chaque base de code du parc était documentée.

Les balayages remplissent une double fonction, révélant comment chaque système fonctionne et ce qu'il fait pour les citoyens. La fonction d'affaires de chaque application a été cartographiée dans une hiérarchie de capacités d'affaires, ce qui nous permet de catégoriser chaque application selon sa fonction. La fiche combinée de chaque dépôt va bien plus en profondeur que tout inventaire que nous avions auparavant. Cela a aussi permis de faire le point sur les redondances de fonctions que nous pouvons cibler en vue d'une rationalisation. Comme nous le soulignons dans le prochain document, nous croyons pouvoir, dans certains domaines, réduire de 10 pour 1 notre code redondant grâce à la standardisation des fonctions communes pilotée par l'IA.

Les résultats de cette analyse Git Insights aboutissent dans une seule base de données et sont exposés au moyen d'un tableau de bord pour la direction. On y trouve une vue de direction de la santé et du risque, une grille à neuf cases qui situe chaque système selon son degré d'activité par rapport à son degré de santé, des fiches de santé du code par dépôt, des profils de contributeurs et la répartition des dispositions, le tout exportable vers un document, une feuille de calcul ou des données brutes. Le regroupement approfondi entre dépôts, où des centaines de systèmes qui se chevauchent dans un seul ministère sont regroupés en un ensemble plus restreint de capacités reconstruites, constitue son propre moteur et son propre document; voir Git Insights Ministère.

"Pour la première fois, un sous-ministre pouvait poser une question sur le parc et obtenir une réponse ancrée dans le code lui-même." · Document 3 · Git Insights


## §04 À quoi ressemblait réellement le parc

Le balayage terminé, nous pouvions enfin mesurer ce que nous n'avions toujours fait qu'estimer. Le domaine que Git Insights a cartographié était plus vaste que quiconque ne l'avait dénombré.

Les lacunes structurelles étaient plus révélatrices encore. À travers environ 3 400 dépôts, les pratiques qui rendent le code sûr à modifier faisaient défaut bien plus souvent qu'elles n'étaient présentes.

Chaque dépôt a été noté sur dix quant à sa santé globale, à travers la qualité du code, la sécurité, les tests et la documentation. À travers l'ensemble du parc, la moyenne s'est révélée faible, tirée vers le bas par les tests, les pipelines et la documentation manquants notés plus haut.


## §05 Nous mesurer nous-mêmes

Nous avons aussi mesuré les habitudes de notre personnel et de nos sous-traitants. Nous n'en avons pas fait une mesure punitive ni une mesure de rendement. Nous l'avons mesuré pour repérer où la variance humaine ordinaire dégrade nos contrôles de sécurité et nos meilleures pratiques, afin de savoir où la formation et de meilleurs outils aideront le plus. À travers plus de huit mille cent contributeurs et huit ans d'historique, le constat était clair.

Ces lacunes ne sont pas l'œuvre d'acteurs malveillants. Elles proviennent de personnes ordinaires et travaillantes, aux niveaux de compétence variés. Mais sur des décennies et des milliers de personnes, des constats clairs ont émergé, révélant des lacunes structurelles nettes. Malgré les politiques et une documentation de processus claire, des étapes sont fréquemment omises. Les standards évoluent aussi avec le temps, et de nouveaux standards comme la conteneurisation et les pipelines de construction automatisés n'ont pas fait leur chemin dans les bases de code héritées. Des contributeurs individuels ont aussi démontré des omissions répétées dans l'hygiène du code, qui peuvent être corrigées par l'éducation.

Sous les paliers de risque, Git Insights bâtit un profil complet de chaque contributeur, tiré de la fiche plutôt que de l'opinion.


## §06 Humain + IA : comparaison et partenariat

Une grande quantité de critiques visent l'IA pour les erreurs qu'elle commet. Beaucoup d'encre est versée à décrire son potentiel d'hallucination et de biais. Cependant, ces récits révèlent un fort biais de récence dans la façon dont nous, humains, rendons compte de ces échecs. Une mauvaise réponse de l'IA est retenue, les dix mille bonnes ne le sont pas. De telles critiques de l'IA commettent souvent l'erreur plus grave de ne pas tenir compte aussi de la performance humaine dans un domaine équivalent. 


Nos constats étaient clairs : avec les contrôles appropriés décrits dans le document sur le harnais, les plus récents outils de codage par IA commettent moins d'erreurs que les humains sur des tâches équivalentes de codage et d'analyse.

Git Insights nous a donné le point de référence pour faire cette affirmation avec des preuves. Les métadonnées récoltées dans GitHub ont produit la toute première étude à grande échelle et longitudinale en Alberta sur la performance technique humaine. Nous avons mesuré le travail réel de plus de huit mille personnes sur huit ans : chaque validation, chaque demande de tirage et l'état du code qu'elles ont produit, à travers l'ensemble du parc. Ce processus nous a donné un point de référence pour mesurer nos investissements futurs dans la vitesse, la qualité, la sécurité et le processus de l'IA. 

Les humains et l'IA commettent tous deux des erreurs. Et nous sommes tous deux des résolveurs de problèmes créatifs. Le constat à retenir de cette analyse, c'est que les technologies évoluent, que les niveaux de compétence entre humains sont plus variables qu'entre les plus récents modèles, et que travailler de façon créative avec l'IA procure le meilleur des deux mondes. 


L'IA prêtant une plus grande assistance au codage, les efforts humains se déplacent vers l'architecture, la stratégie, la créativité, la conception et, élément crucial, le soutien à l'interaction humaine et à la gestion du changement. La créativité humaine demeure inégalée et fait partie intégrante du processus. Une IA n'a pas imaginé Git Insights. Cela a été piloté à 100 pour cent par des humains. Mais elle a rendu possible l'analyse en bonne et due forme d'un vaste parc numérique, pour presque rien (moins de deux mille dollars), et en quelques heures seulement. Dans un partenariat bien formé entre l'humain et l'agent d'IA, les erreurs peuvent être repérées immédiatement, résolues rapidement, et la vélocité vers l'avant accrue. 

Le prochain document élève Git Insights d'un cran, à l'échelle du ministère, où des centaines de systèmes qui se chevauchent sont lus ensemble et regroupés en un ensemble plus restreint de capacités modernes et reconstruites, assorties d'un plan chiffré. Voir Git Insights Ministère.

Tags: git-insights, code-analysis, agents, technical-debt, cybersecurity

Open the interactive version