No. 08 · Technical

L’usine d’IA : conception et idéation (Pronghorn)

Le projet Pronghorn représente la première des trois étapes de l’usine. Les outils d’intelligence artificielle transforment les exigences ministérielles en prototypes, en artéfacts, en canevas visuels et en livrables de projet, et ce, avant même le démarrage du processus de construction.

À la fin de 2025, l’équipe des maximalistes de l’IA au sein de Technologie et Innovation avait « vibe-codé » plusieurs centaines d’applications prototypes sur des plateformes comme Lovable. À mesure que les modèles gagnaient en performance et que le personnel développait son expertise, le développement et le prototypage d’applications s’accéléraient. Cependant, les agents d’IA se concentraient principalement sur l’expérience utilisateur et prenaient des décisions architecturales non documentées, ce qui compromettait la sécurité, le déploiement et l’adéquation aux charges de travail gouvernementales. Par ailleurs, ces plateformes imposaient certains choix technologiques précis (comme l’utilisation de Supabase et d’autres solutions de logiciel en tant que service), qui ne correspondaient pas à nos normes et qui, lorsqu’ils étaient mal appliqués, pouvaient facilement introduire de nouveaux risques de sécurité.

Soyons clairs : ces lacunes ne sont pas liées aux capacités des modèles eux-mêmes, mais plutôt à la manière dont ils sont utilisés. Le personnel ne semble pas mettre en place, dès le départ, des contrôles de sécurité robustes, et la livraison des solutions dorsales se caractérisait par une planification insuffisante, un manque de cohérence et une mise en œuvre improvisée. Il est rapidement apparu que l’Alberta avait besoin d’outils à la fois simples d’utilisation et suffisamment puissants pour offrir une vision intégrée de ce qui est en cours de conception avant même le début du développement. De nouveaux processus doivent être instaurés pour formaliser ces étapes et s’assurer qu’elles ne soient plus négligées. En novembre 2025, l’équipe des maximalistes de l’IA a donc entrepris de concevoir une solution pour relever ces défis, solution qui est devenue par la suite le projet Pronghorn.


## §01 Voici pronghorn

Le pronghorn constituait la mascotte idéale pour cette initiative. Deuxième animal terrestre le plus rapide au monde et le plus rapide d’Amérique du Nord, originaire de l’Alberta, il se distingue par son vaste champ de vision et son endurance lui permettant de courir pendant des heures. Nous souhaitions un outil doté de qualités similaires : rapide, capable d’anticiper et de maintenir une vélocité élevée sur de longues périodes. Notre ambition initiale était de faire de Pronghorn une solution unique et complète couvrant l’ensemble du cycle de construction, des exigences et du prototypage jusqu’à l’architecture, à la gestion des données et au déploiement. La version initiale y est parvenue de manière partielle, en permettant notre première réalisation de bout en bout au sein d’une plateforme commune. Cependant, à mesure que la technologie progressait et que les plateformes de codage agentique, telles que Claude Code, GitHub Copilot et Perplexity Computer, évoluaient, nous avons recentré la portée de Pronghorn afin de nous concentrer plus précisément sur la transformation des idées et des exigences en prototypes, en architectures et en artéfacts nécessaires au démarrage d’un projet. Il s’agissait, et il s’agit toujours, d’une étape du processus de développement insuffisamment outillée et souvent négligée. Nous avons donc opéré un pivot et fait preuve d’agilité (à l’image du pronghorn), en orientant davantage la plateforme vers la première des trois étapes de ce que nous appelons une usine d’IA.


## §02 L’usine d’IA en trois étapes

Le concept d’usine d’IA consiste à exploiter pleinement l’IA agentique afin de piloter le développement des applications, de l’idéation jusqu’à la mise en production. L’objectif de l’Alberta est de maximiser l’utilisation de l’IA pour accroître la qualité et la rapidité, tout en réduisant les coûts. Pour y parvenir efficacement, le processus a été structuré en trois étapes distinctes.

La première étape consiste à rassembler la matière première, notamment les exigences, les dépendances, les transcriptions ainsi que les processus et flux de travail existants. L’IA soutient cette étape en transformant ces artéfacts en prototypes, en conceptions, en exigences, en spécifications claires et en livrables de projet tels que des analyses de rentabilisation, des chartes et des architectures bien définies. La deuxième étape porte sur la construction, tandis que la troisième vise la mesure.

Pronghorn intervient dans cette première étape, où sont définis les éléments communs, les composantes, les spécifications et l’architecture, et où l’on précise concrètement ce que l’on cherche à construire.


## §03 L’usine automobile comme analogie utile

Une usine automobile constitue une analogie utile pour comprendre le processus de conception des applications à l’ère de l’IA.

De nombreuses conceptions automobiles débutent par un bloc d’argile, façonné par un designer possédant un sens du style et respectant un ensemble de contraintes strictes : la forme doit être aérodynamique, attrayante, sécuritaire sur la route et conforme aux exigences en matière de garde au sol, de hauteur, de vitrages et de portières. L’argile ne représente que l’apparence, ce qui suffit comme point de départ. Une fois sculptée, elle est numérisée, convertie en modèle 3D, puis affinée à l’aide de logiciels pour devenir un concept plus robuste.

Viennent ensuite les spécifications. Au Canada, Transports Canada définit les exigences auxquelles un véhicule doit répondre pour être homologué, établissant ainsi un ensemble complet de normes de sécurité. S’ajoute à cela le travail d’ingénierie : une conception est traduite en des dizaines de milliers de pièces distinctes, chacune préfabriquée et documentée selon sa propre conception, ses matériaux et sa fiche technique, l’ensemble étant d’abord assemblé virtuellement. Des outils de validation permettent de vérifier l’absence de conflits entre les pièces et de s’assurer que chacune peut être installée et retirée en séquence à l’aide d’outils standards.

Le développement logiciel traditionnel (pré‑IA) suit des processus comparables à ceux de la conception automobile. Des prototypes visuels et des maquettes filaires sont réalisés pour valider les hypothèses de base. L’image de marque et les styles sont intégrés, les décisions architecturales sont prises et les normes organisationnelles sont appliquées aux plans. Les exigences fonctionnelles (ce que l’utilisateur voit et fait) et non fonctionnelles (le fonctionnement et la sécurité de l’application) sont définies, puis validées par différents intervenants. Les coûts sont détaillés par composante et par fonctionnalité, et un calendrier assorti d’un budget est établi et approuvé.

En revanche, le développement d’applications fondé sur l’IA tend à omettre une grande partie, voire la majorité, de ces étapes, en se lançant directement dans la conception de l’interface utilisateur et des flux de travail. Cela procure une gratification visuelle immédiate, mais reporte des décisions essentielles à plus tard. Pour reprendre l’analogie, on obtient la carrosserie de la voiture, mais sans les freins, le moteur, les essieux ni le châssis : un résultat attrayant sur le plan visuel, mais ni prêt ni sécuritaire à être utilisé.


## §04 Automatisation contre fabrication artisanale

L’usine indique la direction à suivre en matière de normalisation.

Les humains eux-mêmes ont de la difficulté à assurer la cohérence d’une application à l’autre. En l’absence de normes clairement définies, deux développeurs prendront des décisions variées qui influenceront l’expérience utilisateur. Pour un produit logiciel distinct, cette singularité peut être un atout. Toutefois, dans le contexte gouvernemental, elle constitue généralement un désavantage.
Bien que le gouvernement valorise une expérience utilisateur de qualité et la créativité permettant de résoudre des problèmes inédits, des critères comme la reproductibilité, la sécurité, la convivialité et l’accessibilité revêtent une importance bien plus grande que le caractère unique ou sur mesure. À travers des milliers de services destinés au public, toute divergence par rapport à une apparence homogène tend à semer la confusion plutôt qu’à séduire.

Au fil des décennies et des initiatives menées par différents ministères, l’expérience utilisateur s’est fragmentée. Si chaque application vise la cohérence au sein de sa propre base de code, l’ensemble du parc technologique présente une grande hétérogénéité, souvent déroutante pour les usagers. Pour une personne à la recherche de services sociaux, notamment si elle utilise un lecteur d’écran ou une autre technologie d’assistance, ce manque de cohérence peut faire toute la différence entre accéder à de l’aide ou abandonner la démarche. La norme doit donc aller à la rencontre du public, là où il se trouve.

La livraison assistée par l’IA peut accentuer ce problème, car chaque prototype développé par « vibe‑coding » tend à différer des autres en l’absence de normes claires établies dès la toute première étape. Toutefois, l’IA peut également contribuer efficacement à sa résolution en définissant des normes universelles auxquelles chaque agent d’IA se conforme. Cela nécessite la mise en place d’un dépôt central, lisible par la machine, regroupant des normes, des gabarits et des exemples de code, tels qu’une bibliothèque de composantes communes et réutilisables, qui sont définis et appliqués de manière cohérente tout au long du processus de construction. Le Well Built Harness est un exemple de la façon dont ces normes peuvent être appliquées.

L’Alberta cherche à réduire cette complexité grâce à une mise en œuvre appuyée par l’IA. En s’appuyant sur une approche fondée sur des normes, nous simplifions cette complexité en la ramenant à un ensemble clair et partagé de standards lisibles par l’IA. Cela permet d’assurer une expérience conviviale, de garantir l’accessibilité et de maintenir une cohérence sur l’ensemble des interfaces utilisées par les citoyens. En mettant en œuvre Les quatre approches de la modernisation par l’IA, nous harmonisons cette expérience selon les approches qui y sont présentées. Ces normes et ces approches sont appliquées dès la première étape de l’usine, par l’entremise de la plateforme Pronghorn.


## §05 Pronghorn

L’Alberta a conçu la première version de Pronghorn (appelée Pronghorn Red) comme une application React/Supabase à code source ouvert. Elle reposait initialement sur Lovable et était intégrée à Render.com ainsi qu’à des fournisseurs infonuagiques tiers pour l’hébergement et l’intégration des bases de données. Elle prenait en charge une variété de modèles provenant de Google, d’Anthropic et de SpaceXAI, et offrait une suite d’outils assistés par l’IA soutenant le cycle de vie du développement d’applications.

Plus récemment, l’Alberta a collaboré avec Microsoft Canada pour faire évoluer Pronghorn vers une version remaniée, appelée Pronghorn Blue, mieux adaptée aux environnements d’entreprise. Cette version introduit le support des modèles d’OpenAI et s’appuie sur des composantes natives de la pile Azure, notamment pour les bases de données et les déploiements conteneurisés. Pronghorn Blue est maintenu dans le cadre d’un partenariat entre Microsoft et le gouvernement de l’Alberta, et fera l’objet de développements continus au cours de la prochaine année afin d’y ajouter de nouvelles fonctionnalités. Pronghorn Red demeure une architecture de référence pertinente, mais n’est plus en développement actif. Les deux versions peuvent être déployées par toute organisation dans son propre environnement infonuagique, qu’il soit privé ou public. Elles sont toutes deux publiées sous licence MIT, ce qui permet une utilisation libre et sans restriction.


## §06 D’une idée à une spécification

Un projet dans Pronghorn débute par la saisie de quelques métadonnées et le choix des modèles, puis évolue rapidement vers un clavardage avec la plus récente IA. Ce mode de clavardage, familier, introduit toutefois une capacité de prototypage rapide : les applications décrites apparaissent immédiatement dans l’interface, ce qui permet de développer les idées plus efficacement. Ainsi, une personne sans expertise technique, et sans infrastructure pour héberger une application, peut décrire ses besoins et voir émerger en temps réel une maquette fonctionnelle, prête à être partagée avec un client afin de recueillir ses commentaires. Il est possible de conserver un nombre illimité de fils de discussion, de cloner des conversations et de télécharger l’ensemble des échanges. À cet égard, nous rappelons qu’une plateforme qui ne permet pas d’exporter le contenu des conversations présente une lacune fondamentale : ce contenu constitue votre propriété intellectuelle et doit pouvoir être conservé, exploité et transmis à un agent. Pronghorn répond à cette exigence.

Vient ensuite l’espace des artéfacts, où Pronghorn offre des fonctionnalités approfondies : un agent n’est performant que dans la mesure du contexte qui lui est fourni. Les projets démarrent généralement à partir d’un ensemble varié d’artéfacts — présentations, PDF, documents Word, pages Web — que cet espace intègre, indexe et met à la disposition de l’IA. Pronghorn permet également de générer et d’analyser des images, de sorte qu’une maquette d’interface utilisateur peut être créée à l’aide d’un modèle d’image, puis affinée directement sur place. Tous les artéfacts peuvent être modifiés en collaboration dans un éditeur assisté par l’IA, qui conserve un historique immuable de chaque modification. Il devient ainsi possible de rédiger et de réviser rapidement tout type de document, avec un véritable contrôle de version, des capacités de traitement des images et des PDF, ainsi qu’une gestion structurée des fichiers.

À partir des clavardages et des artéfacts, Pronghorn élabore les exigences d’affaires. En pointant l’outil vers le contenu pertinent, celui‑ci le parcourt selon une hiérarchie agile et structurée : les épopées au sommet, suivies des fonctionnalités qu’elles regroupent, puis des récits utilisateurs et, enfin, des critères d’acceptation qui définissent les conditions de complétion. Le résultat prend la forme d’une carte structurée à quatre niveaux, qui peut être développée, suivie et transmise, et qui demeure ancrée dans les documents à l’origine du projet, plutôt que dans les souvenirs de réunions.


## §07 Le canevas d’architecture

La fonctionnalité qui suscite le plus d’enthousiasme le plus à long terme est un canevas visuel partagé, construit sur React Flow, qui permet de glisser-déposer les différentes composantes de l’architecture d’une application et de collaborer avec des agents d’IA capables à la fois de lire le canevas et d’y intervenir.

Une application moderne comporte de nombreuses couches : l’infrastructure infonuagique où elle s’exécute, le pare-feu, le frontal, les serveurs, les API tierces, les bases de données ainsi que les intégrations internes. Représentée sous forme d’architecture fonctionnelle, elle se traduit par des dizaines, voire des centaines de composantes interconnectées au sein d’un même diagramme. Dans Pronghorn, il est possible de générer une architecture théorique dès le départ, de s’y attarder et d’en conserver des versions successives décrivant l’ensemble de l’application, et ce, avant même qu’une seule ligne de code ne soit écrite. C’est essentiel, car cela permet d’éviter que l’interface soit simplement « vibe‑codée » jusqu’à exister. Contrairement à la production longue et verbeuse d’un modèle de langage, le canevas offre une représentation compacte et structurée : une hiérarchie claire de nœuds reliés par des arêtes étiquetées, enrichies de métadonnées décrivant leur rôle et leurs interactions. Il constitue ainsi un point de départ optimal pour la phase de construction et peut être exporté pour être transmis directement à un agent de codage. La forme d’une application d’entreprise doit être définie de manière intentionnelle dès le départ, plutôt que laissée aux choix d’un modèle imprévisible au fil de l’eau. Le canevas représente l’architecture fonctionnelle, laquelle constitue en soi une exigence — plus précisément, une exigence non fonctionnelle. En combinant les exigences fonctionnelles issues de la section dédiée avec l’architecture du canevas, on obtient une spécification complète et explicite du comportement attendu de l’application.


## §08 Des agents qui préparent le projet

Pronghorn est livré avec un ensemble d’agents qui préparent un projet en vue de son approbation et de sa mise en œuvre. Un rédacteur d’analyse de rentabilité, un rédacteur de charte et d’appel d’offres, un planificateur de projet et un générateur d’échéancier analysent vos clavardages, vos artéfacts et vos canevas afin de produire un plan de projet prêt à être présenté à un client pour obtenir son adhésion. Il est également possible de modifier ces agents, d’en créer de nouveaux et de les organiser en flux de travail, afin de transformer une idée initiale en un ensemble complet d’artéfacts nécessaires au démarrage d’un projet.

Pronghorn comprend également des agents de codage et un agent dédié aux bases de données, offrant des moyens rapides de faire passer une idée à l’échelle : importation de données en formats JSON ou CSV, connexion à un large éventail de bases de données et utilisation d’une base de données Postgres hébergée sur Azure, Render, AWS ou d’autres plateformes, avec un déploiement simplifié dans Azure et sur Render.com dans l’édition Red. Ces capacités de construction et de déploiement relèvent désormais davantage de l’étape suivante de l’usine, Nexus, qui ajoute les contrôles de sécurité et les capacités d’observabilité des agents que Pronghorn n’a jamais été conçu pour prendre en charge.


## §09 Le premier tiers de l’usine

Pronghorn constitue la première phase critique : la recherche et l’idéation, le développement de l’architecture et la cartographie des exigences. Placé aux côtés des exigences, des documents et des transcriptions de réunions du client, il ancre une application d’entreprise dans un ensemble clair d’artéfacts qu’un agent de codage agentique peut lire nativement. Pronghorn expose ces connexions dans les deux sens. Un agent d’écoute dans Claude Code peut surveiller les changements apportés à un projet Pronghorn, tandis qu’une API permet à toute plateforme de codage agentique d’y écrire directement, de sorte qu’un agent devient un contributeur à part entière, capable d’enrichir l’architecture, les exigences et les artéfacts. À partir de Nexus, les deux se relient dans les deux sens, et le développement est piloté à partir de là.

À nos équipes de réalisation : la tentation, dans le développement agentique, est de se lancer immédiatement dans la construction de l’application. C’est gratifiant, cela permet de tester rapidement une idée, mais c’est aussi ainsi que l’on se retrouve avec une architecture mal alignée avec la pile technologique à respecter. Pronghorn est l’endroit où les parties prenantes, techniques comme non techniques, s’entendent sur la portée, les plans et les exigences avant de passer à l’action. Rien n’y est figé : les artéfacts peuvent être extraits proprement et transmis directement à l’étape de construction. Sauter cette étape comporte des risques importants : vous risquez de livrer des applications qui paraissent adéquates, qui respectent en apparence les normes communes, mais qui offrent en réalité une expérience incohérente et inégale sous la surface, notamment au niveau de la couche API, où la prestation des services dans le modèle Gouvernement 3.0 décrit dans les quatre approches se gagne ou se perd. Le prochain document montre où ces spécifications se rejoignent et sont mises en œuvre, dans l’environnement Nexus, par les agents qui font la construction.

Tags: ai-factory, pronghorn, design, requirements, canvas, architecture, open-source

Open the interactive version