No. 03 · Technical

Git Insights

Nous avons utilisé l’IA pour analyser l’ensemble du parc de code du gouvernement de l’Alberta afin d’en établir une vision précise de la réalité. Voici comment cette démarche fonctionne et ce qu’elle a permis de révéler.

Comme dans bien des grandes organisations, GitHub Enterprise est la plateforme principale pour gérer le code. Elle offre déjà des outils puissants d’analyse, comme CodeQL pour l’examen du code, ainsi que des intégrations avec NPM et Maven pour détecter les vulnérabilités dans les dépendances. Les secrets sont automatiquement repérés et bloqués, et l’équipe de cybersécurité dispose de mécanismes de contrôle intégrés. Toutefois, ces outils reposent surtout sur des règles fixes, ce qui entraîne un nombre élevé de faux positifs. Surtout, ils ne couvrent pas des éléments essentiels comme l’absence de documentation, de processus automatisés de déploiement ou de tests unitaires. Enfin, ils ne permettent pas d’obtenir une vue d’ensemble fiable de la santé globale des systèmes. Pour comprendre réellement l’état de la technologie gouvernementale, il fallait donc aller plus loin et analyser le code en profondeur.


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

Reconstituer une vue d’ensemble d’une grande organisation peut être très difficile. Dans leur état actuel, nos principaux systèmes officiels ne pouvaient pas être reliés entre eux. Les informations sur les dépendances provenant de GitHub n’étaient pas intégrées à notre base de données de gestion des configurations. Cette base, hébergée dans ServiceNow, était mise à jour manuellement et contenait plus de 100 000 entrées liées à ces applications. Les renseignements concernant nos applications étaient dispersés dans plusieurs outils et emplacements : GitHub, des billets Jira, Confluence, des outils de suivi des incidents, de la documentation SharePoint et de nombreux fichiers Excel. Comme ces données non structurées n’avaient aucune clé commune pour les relier entre elles, il était jusque-là pratiquement impossible de les regrouper.

Entrées de la CMDB tenues à jour manuellement 100 000+. Conservées dans ServiceNow sans aucun lien automatisé avec GitHub, les données suivaient une structure logique allant du ministère au projet ou programme, puis à l’application et au dépôt, avant de se décliner en sprints, en entrées de CMDB, en billets et en documentation. Toutefois, aucun de ces éléments n’était réellement connecté aux autres.

Le résultat était clair : aux niveaux de la haute direction, comme ceux du sous‑ministre et du sous‑ministre adjoint, il était impossible d’obtenir des réponses fiables à partir des outils existants. De leur côté, les équipes avaient de la difficulté à produire des constats précis. GitHub lui-même risquait de devenir un environnement confus, où des prototypes côtoyaient des systèmes en production sans distinction claire. Nous ne pouvions pas dire avec certitude ce que nous exploitions, dans quel état c’était, ni où se situaient réellement les risques. Nous avons donc décidé d’agir.


## §02 Bâtir un éclaireur

En utilisant Claude Code comme agent de développement, les modèles Opus et Sonnet pour l’analyse, et Google Enterprise Agent Platform comme couche agentique, l’Alberta a créé un outil nommé **Git Insights**. Cet outil, basé sur des agents d’IA, parcourt de façon systématique l’ensemble du parc GitHub. Il agit comme un éclaireur : il inspecte chaque dépôt pour rapporter ce qu’il contient réellement. Dans ce contexte, le code devient la source la plus fiable pour comprendre la réalité sur le terrain.

Lues par les agents en une vingtaine d’heures 466 millions de lignes. Un balayage complet du parc, qu’aucun mandat de consultation n’aurait pu réaliser aussi rapidement ni à un coût comparable. Un tiers des dépôts ne contenait aucune documentation ; les agents l’ont donc générée, et toutes les dépendances ont été identifiées.

Le moment de cette analyse était crucial. L’Alberta a observé une augmentation importante des vulnérabilités connues dans l’ensemble de ses systèmes. Dans les outils de suivi, on voit clairement une hausse marquée qui coïncide avec l’arrivée de modèles plus avancés comme Mythos d’Anthropic, les nouvelles versions d’Opus, ainsi que GPT‑5.4 et 5.5 d’OpenAI. La même capacité qui permet à un outil comme Git Insights d’analyser en profondeur le code est aussi celle qui permet à des acteurs malveillants de repérer les failles plus facilement, un enjeu détaillé dans le document sur la cybersécurité. Dans les quatre semaines suivant la sortie de Mythos, l’Alberta a donc conçu ses propres outils et méthodes pour mener ce type d’analyse de façon rapide et structurée.


## §03 Comment fonctionne Git Insights

Git Insights fonctionne de manière assez simple. Il repose sur deux niveaux. D’abord, un ensemble d’agents parcourt tout le parc de code en une seule fois. Ensuite, à l’intérieur de chaque dépôt, chaque agent suit la même méthode. Un moteur de règles analyse le code pour repérer des éléments connus qui nécessitent une analyse plus approfondie. Puis, l’agent d’IA intervient pour examiner ces éléments et porter un jugement. Tous les constats sont enregistrés et peuvent être vérifiés par une personne, jusqu’à la ligne de code qui les justifie.

Les agents s’exécutent sur Google Enterprise Agent Platform. Google a travaillé en étroite collaboration avec l’Alberta pour assurer une capacité de traitement élevée, atteignant jusqu’à 25 millions de jetons par minute, afin d’accélérer l’analyse. L’outil a aussi été conçu pour être robuste. Si une analyse échoue ou atteint une limite, elle est mise en attente puis relancée, pendant que les autres continuent. Et si l’ensemble du processus est interrompu, il reprend exactement là où il s’était arrêté. C’est cette capacité qui permet à Git Insights d’analyser 466 millions de lignes de code, réparties sur des milliers de dépôts, en environ vingt heures, en poussant au maximum les capacités de traitement disponibles.

Une question importante est de savoir dans quelle mesure on peut se fier aux résultats de l’IA. Trois éléments assurent sa fiabilité. D’abord, le travail répétitif et mesurable, comme recenser les fichiers ou détecter des motifs connus est fait par du code classique, qui ne peut pas inventer de résultats. Ensuite, les conclusions de l’IA ne sont jamais acceptées sans preuve : pour chaque problème, elle doit identifier précisément l’endroit dans le code, expliquer la gravité et proposer une correction, afin qu’un développeur puisse vérifier. Enfin, chaque dépôt est évalué selon une grille fixe couvrant la sécurité, la qualité du code, l’architecture, la documentation, les tests, la maintenabilité et la santé des dépendances. Cela garantit que les évaluations sont cohérentes d’un dépôt à l’autre. Tous les constats sont enregistrés dans une base de données et peuvent être vérifiés directement dans le code. Cette base permet ensuite d’effectuer des analyses globales, notamment par d’autres agents utilisés par les équipes de cybersécurité et de livraison, afin d’identifier des tendances et des problèmes communs à l’ensemble du parc.

Chaque balayage permet de révéler les technologies anciennes encore présentes, comme le COBOL, l’ASP classique ou des versions de Dot NET et de Java qui ne sont plus supportées. Il permet aussi d’identifier à quel ministère ces systèmes appartiennent. Toutes les dépendances sont recensées, constituant enfin un inventaire précis que la base de gestion des configurations n’avait jamais pu fournir. L’outil signale également les dépôts contenant des renseignements personnels sensibles, rendant visibles des risques auparavant cachés. Pour les 1 280 dépôts sans documentation, l’agent l’a générée automatiquement à partir du code, tout en vérifiant et en améliorant les README existants. Pour la première fois, l’ensemble du parc est ainsi entièrement documenté.

Les balayages ont un double rôle : ils montrent à la fois comment chaque système fonctionne et ce qu’il fait concrètement pour les citoyens. Les fonctions d’affaires de chaque application sont cartographiées dans une hiérarchie claire de capacités, ce qui permet de classer les systèmes par leur utilité réelle. Chaque dépôt dispose ainsi d’une fiche beaucoup plus détaillée que tout ce qui existait auparavant. Cette vue d’ensemble met aussi en évidence les redondances, que l’on peut ensuite cibler pour les éliminer. Comme cela sera abordé dans le document suivant, l’objectif est de réduire fortement le code dupliqué, parfois jusqu’à un facteur de dix, en standardisant les fonctions communes grâce à l’IA.

Les résultats de l’analyse réalisée par Git Insights sont regroupés dans une seule base de données et présentés dans un tableau de bord destiné à la direction. On y trouve une vue d’ensemble de la santé des systèmes et des risques, une grille à neuf cases qui positionne chaque système selon son niveau d’activité et son état de santé, des fiches détaillées par dépôt, des profils de contributeurs ainsi qu’une répartition des différents constats. Toutes ces données peuvent être exportées en document, en feuille de calcul ou en données brutes. L’analyse plus poussée entre plusieurs dépôts — où des centaines de systèmes qui se chevauchent dans un même ministère sont regroupés en un ensemble plus restreint de capacités reconstruites, repose sur un moteur distinct et fait l’objet d’un document séparé; 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

Une fois le balayage terminé, nous avons enfin pu mesurer ce que nous n’avions jusque-là qu’estimé. Le périmètre cartographié par Git Insights s’est révélé beaucoup plus vaste que ce que quiconque avait réussi à dénombrer auparavant.

Les lacunes structurelles étaient encore plus frappantes. Sur environ 3 400 dépôts, les bonnes pratiques essentielles pour rendre le code fiable et facile à modifier étaient souvent absentes plutôt que présentes.

Chaque dépôt a reçu une note sur 10 pour évaluer sa santé globale, en tenant compte de la qualité du code, de la sécurité, des tests et de la documentation. À l’échelle de l’ensemble du parc, la moyenne s’est révélée faible, notamment en raison du manque de tests, de pipelines automatisés et de documentation, déjà relevé plus tôt.


## §05 Nous mesurer nous-mêmes

Nous avons aussi analysé les contributions de code de notre personnel et de nos sous-traitants. Nous l’avons fait pour repérer où la variabilité humaine ordinaire érode nos contrôles de sécurité et nos normes, afin de savoir où la formation et de meilleurs outils aideront le plus. Une analyse rétrospective au moyen d’un outil comme Git Insights ne peut pas connaître le contexte derrière une décision prise par une personne un jour donné. Ce qu’elle fait, c’est révéler les tendances, agrégées à grande échelle et de façon anonymisée. Sur plus de huit mille cent contributeurs et huit ans d’historique, ces tendances étaient claires.

Les plus grands écarts observés concernaient la cohérence et l’adhésion aux normes. À noter, il ne s’agit pas d’une critique d’un travailleur ou d’un groupe, ni d’un signe de mauvaise intention. Les développeurs contributeurs forment, dans l’ensemble, un groupe compétent et travaillant, et la plus grande partie du code applicatif qu’ils ont produit était solide à l’époque. Les problèmes que les données ont révélés étaient systémiques. En huit ans, plus de huit mille personnes, dont beaucoup ont été recrutées comme sous-traitants individuels dans des ministères distincts, ont travaillé selon des normes souvent non documentées, communiquées de façon inégale, et passées sous silence dans les contrats eux-mêmes. Beaucoup de ces normes sont aspirationnelles et fondées sur des principes plutôt que prescriptives et précises, ce qui laisse un écart entre l’intention de l’auteur et l’interprétation et l’application qu’en fait le lecteur. Lorsque les règles ne sont pas définies, il est normal, et presque inévitable, que des personnes compétentes fassent leurs propres choix et suivent la voie de la moindre résistance. C’est ce qui mène au type de dérive observé dans l’analyse Git. Les normes évoluent aussi avec le temps. De nouvelles pratiques comme la conteneurisation et les chaînes de construction automatisées n’ont jamais atteint le code plus ancien, et sur un parc aussi vaste, il n’existait aucun moyen pratique de vérifier l’adhésion aux normes. Ce dernier manque, l’incapacité de voir les tendances de l’ensemble, est celui que l’IA agentique a maintenant comblé.

Vu sous cet angle, le parc avait grandi comme une ville médiévale. Chaque structure a été érigée pour répondre au besoin de son époque, solide à ses propres conditions, mais l’ensemble est devenu dense et difficile à parcourir après coup. Une analyse fondée sur des règles comme Git Insights trace des lignes droites à travers cette croissance organique. Le précédent le plus proche est le plan de Paris du baron Haussmann, dont les larges boulevards ont été percés dans le tissu médiéval pour imposer ordre et connexion après des siècles de construction non planifiée. Il en résulte la ville à deux couches que nous connaissons aujourd’hui : une croissance organique mariée à un plan rationnel posé par-dessus. Il serait injuste de juger déficient ce que huit mille développeurs ont bâti en huit ans. Mais il serait tout aussi faux de présumer qu’il faut simplement le reproduire. Il nous reste un problème difficile, et le résoudre rapidement exigera des gestes structurants et délibérés, à cette échelle. Pour relever un défi d’une telle ampleur, nous devons adopter de nouvelles façons de travailler.


## §06 Humain + IA : partenariat

Une grande partie des critiques envers l’IA porte sur ses erreurs. On insiste beaucoup sur ses hallucinations et ses biais. Mais cette critique reflète souvent un biais de perception : on retient facilement une mauvaise réponse, alors que des milliers de bonnes passent inaperçues. Surtout, ces critiques oublient un point essentiel : elles ne comparent pas la performance de l’IA à celle des humains dans des situations équivalentes.


Nos constats sont clairs : avec les contrôles appropriés décrits dans le document sur le harnais, les plus récents outils de codage par IA peuvent aider à accroître la cohérence des tâches de codage et d’analyse, au sein d’une même application comme à l’échelle de tout le parc.

Git Insights nous a donné le point de repère nécessaire pour appuyer cette affirmation avec des preuves. Les métadonnées recueillies dans GitHub ont permis de réaliser, pour la première fois en Alberta, une étude de grande envergure et sur plusieurs années de la performance technique humaine. Nous avons analysé le travail réel de plus de 8 000 personnes sur une période de huit ans : chaque validation, chaque demande de tirage et l’état du code produit, à l’échelle de tout le parc. Cela nous a donné une base concrète pour mesurer, dans l’avenir, les effets de nos investissements en IA sur la vitesse, la qualité, la sécurité et les processus.

Avant l’application des outils fondés sur l’IA, Technologie et Innovation a évalué avec quelle constance les équipes de développement respectaient 100 % des normes à la première livraison de l’application. L’adhésion complète aux normes n’était atteinte que dans quarante pour cent des cas à la première livraison, ce qui exigeait des reprises et des versions ultérieures pour finaliser, en raison d’échéances serrées et de l’absence d’une approche fondée sur les normes.

Produits respectant chaque norme à la première livraison 40 %. De nombreuses nouvelles applications nécessitent des reprises modérées à importantes pour respecter toutes les normes, un taux inacceptablement bas.

Comparez ce chiffre à une usine automobile. Nous n’accepterions pas un monde où seulement quarante pour cent des véhicules quitteraient l’usine en satisfaisant aux normes de sécurité. Ce qui fait d’une usine automobile moderne une prouesse d’ingénierie, c’est l’effort consacré à lever l’ambiguïté et à amener chaque unité vers le même résultat élevé, sécuritaire et reproductible. Un système informatique ne devrait pas être tenu à une norme inférieure. Dans un monde numérique, préserver la confidentialité des renseignements des personnes que nous servons est primordial, et l’intégrité de nos institutions et de notre économie dépend désormais de l’intégrité de notre technologie. Les conséquences d’une défaillance informatique peuvent être aussi dommageables que celles d’une défaillance mécanique.

Cette analogie de l’usine nous donne un plan d’ensemble raisonnable pour accroître la qualité et la cohérence. La créativité et le jugement humains s’appliquent au début, dans la conception et l’idéation, et à la fin, dans le service, le soutien et les relations humaines. Au milieu se trouvent l’outillage, les processus et les contrôles qui transforment les bonnes idées et les bonnes conceptions en produits constamment sécuritaires. Conçu en partenariat avec l’IA, ce milieu devient une « chaîne de production » pour le logiciel : des normes appliquées de la même façon chaque fois, sûres en matière de cybersécurité, accessibles et vérifiables par défaut. Ce concept nous donne un modèle pour ce que nous appelons l’« usine d’IA », que les documents ultérieurs déploient étape par étape, à commencer par la conception et l’idéation.

Les humains comme l’IA font des erreurs, et les deux sont des résolveurs de problèmes créatifs. La leçon de cette analyse, c’est que les outils changent. Les personnes qui travaillent de façon créative avec l’IA obtiennent de meilleurs résultats à mesure qu’elles appliquent de nouvelles stratégies et méthodes qui résolvent ces problèmes. À mesure que l’IA prend en charge une plus grande part du codage courant, l’effort humain se déplace vers l’architecture, la stratégie, la créativité, la conception et le travail d’accompagnement mutuel à travers le changement. La créativité humaine demeure inégalée et au centre du processus. Aucune IA n’a imaginé Git Insights; cela était entièrement humain. Ce que l’IA a rendu possible, c’est l’analyse d’un vaste parc numérique pour presque rien, moins de deux mille dollars, en quelques heures. Dans un partenariat bien formé entre une personne et un agent d’IA, les erreurs sont repérées aussitôt, résolues rapidement, et la vitesse d’avancement augmente.

Cela recadre la question que ce document s’était posée. Il n’a jamais été raisonnable d’attendre de plus de huit mille personnes qu’elles tiennent une seule norme de qualité par la seule volonté, encore moins une norme non définie et mouvante sous leurs pieds. La question est maintenant de savoir quoi faire de ce savoir. Grâce à son vaste contexte et à sa rapidité, l’IA peut lire l’ensemble du parc et aider la direction à voir les deux côtés du registre à la fois : là où nos gens excellent, dans la créativité, le lien humain, l’idéation, la perspicacité, l’expérience et le jugement, et là où le système dérive. L’IA peut intervenir pour aider à l’application constante des normes, au suivi des processus et à la vérification des endroits où ils ont été manqués. La rétroaction peut être recueillie, à grande échelle, et mise à profit pour améliorer les résultats. Utilisés ainsi, ces outils nous permettent de protéger la qualité et la sécurité des systèmes dont dépendent les Albertains, sans demander à quiconque d’être moins humain.

Ce qui s’étend ici, c’est le champ des possibles. Le document suivant pousse Git Insights d’un cran, à l’échelle du ministère, où des centaines de systèmes qui se chevauchent sont analysés ensemble et regroupés en un plus petit ensemble de capacités modernes et reconstruites, accompagnées d’un plan chiffré. Voir Git Insights Ministère.

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

Open the interactive version