No. 08 · Technical

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

Le projet Pronghorn constitue la première des trois étapes de l'usine. Les outils d'IA traduisent les exigences ministérielles en prototypes, en artéfacts, en canevas visuels et en livrables de projet avant le début du processus de construction.

À la fin de 2025, l'équipe des maximalistes de l'IA de Technologie et Innovation avait « vibe-codé » plusieurs centaines d'applications prototypes sur des plateformes comme Lovable. À mesure que les modèles gagnaient en capacité et que le personnel acquérait de l'expérience, le développement et le prototypage d'applications s'accéléraient. Cependant, les agents d'IA se concentraient généralement sur l'expérience utilisateur et prenaient des décisions architecturales non documentées qui nuisaient à la sécurité, au déploiement et à la convenance pour les charges de travail gouvernementales. Ces plateformes imposaient aussi des choix technologiques précis (comme l'utilisation de Supabase et d'autres plateformes de logiciel-service) qui ne faisaient pas partie de notre norme et qui, lorsqu'ils étaient mal mis en œuvre, pouvaient facilement introduire de nouveaux risques de sécurité. 

Soyons clairs : ces lacunes n'ont rien à voir avec les capacités des modèles eux-mêmes, mais avec la façon dont ils sont utilisés. Le personnel ne semble pas mettre en place des contrôles de sécurité robustes dès le départ, et la livraison des solutions dorsales était non planifiée, incohérente et improvisée dans sa mise en œuvre. Il était clair que l'Alberta avait besoin d'outils faciles à utiliser pour tous et assez puissants pour créer une image intégrée de ce qui était construit **avant** le début du développement. De nouveaux processus sont nécessaires pour formaliser ces étapes afin de garantir qu'elles ne soient pas escamotées. En novembre 2025, l'équipe des maximalistes de l'IA a commencé à concevoir une solution pour relever ces défis, qui est devenue le projet Pronghorn.


## §01 Voici le pronghorn

Le pronghorn était la bonne mascotte pour cette initiative. Le pronghorn est le deuxième animal terrestre le plus rapide au monde et le plus rapide d'Amérique du Nord, originaire de l'Alberta, doté d'un large champ de vision et de l'endurance nécessaire pour courir pendant des heures. Nous voulions un outil aux mêmes qualités : rapide, capable de voir loin et de maintenir une grande vélocité sur une longue distance. Notre ambition initiale était que Pronghorn devienne une solution unique et complète qui résolve l'ensemble de la construction de bout en bout, des exigences et du prototypage jusqu'à l'architecture, la base de données et le déploiement. La version initiale y est parvenue de façon modérément efficace, permettant notre première construction de bout en bout au sein d'une plateforme commune. Cependant, à mesure que la technologie évoluait et que les plateformes de codage agentique comme Claude Code, GitHub Copilot et Perplexity Computer évoluaient, nous avons resserré la portée de Pronghorn pour 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 lancement d'un projet. C'était, et cela demeure, une étape mal servie et négligée du processus de développement. Nous avons donc pivoté et sommes restés agiles (comme un pronghorn), et la plateforme s'est davantage concentrée sur 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 de l'usine d'IA consiste à tirer le maximum de l'IA agentique pour piloter le développement des applications, de l'idéation à la livraison. L'objectif de l'Alberta est de tirer le maximum de l'IA pour accroître la qualité et la vitesse tout en réduisant les coûts. Pour y parvenir efficacement, nous avons imaginé le processus divisé en trois étapes distinctes. 


La première étape rassemble la matière première, comme les exigences, les dépendances, les transcriptions, ainsi que les processus et flux de travail actuels. L'IA appuie cette étape en transformant ces artéfacts en prototypes, en conceptions, en exigences, en spécifications clairs et en livrables de projet comme des analyses de rentabilisation, des chartes ainsi que des conceptions d'architecture claires et bien documentées. La deuxième construit. La troisième mesure. 


Pronghorn sert cette première étape, où l'on règle les parties communes, les composantes, les spécifications et l'architecture, et où l'on décide de ce qu'on essaie réellement de construire.


## §03 L'usine automobile comme analogie utile

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


Beaucoup de conceptions automobiles commencent par un bloc d'argile, façonné par un artiste qui a un sens du style et un ensemble de contraintes strictes : la forme doit être aérodynamique, attrayante, sécuritaire sur la route et conforme aux limites de garde au sol, de hauteur, de fenêtres et de portières. L'argile n'est que l'apparence, et cela suffit comme point de départ. Une fois sculptée, elle est numérisée, convertie en modèle 3D et raffinée par logiciel en quelque chose de plus solide. Viennent ensuite les spécifications. Au Canada, Transports Canada établit ce qu'une voiture doit respecter pour être légale sur la route, un ensemble exhaustif de normes de sécurité. Et puis les compétences : une conception est convertie en des dizaines de milliers de pièces distinctes, chacune préfabriquée et cataloguée avec sa propre conception, ses matériaux et sa fiche technique, toutes assemblées d'abord à l'intérieur d'un ordinateur. Un logiciel de validation garantit que rien n'entre en collision et que chaque pièce peut être installée et retirée en séquence avec des outils ordinaires. 


Le développement logiciel traditionnel (pré-IA) suit des processus de développement semblables à la conception automobile. Des prototypes visuels et des maquettes filaires sont créés pour valider les hypothèses fondamentales. L'image de marque et les styles sont intégrés. Les décisions architecturales sont prises, et les normes d'entreprise sont superposées aux plans. Les exigences fonctionnelles (ce que l'utilisateur voit et fait) et non fonctionnelles (comment l'application fonctionne et est protégée) sont définies et approuvées pour validation par un éventail de parties prenantes. Les coûts sont ventilés par composantes et fonctionnalités distinctes, et un échéancier et un coût sont fixés et approuvés. 


Le développement d'applications fondé sur l'IA escamote bon nombre, voire la plupart, de ces étapes par défaut, en se lançant directement dans l'interface utilisateur et le flux de travail. Cela procure une gratification visuelle immédiate, mais reporte ces décisions à plus tard. Pour prolonger l'analogie, vous voyez la carrosserie de la voiture, mais les freins, le moteur, les essieux et le châssis sont absents. Visuellement attrayante, mais ni prête ni sécuritaire à conduire.


## §04 Automatisation contre fabrication artisanale

L'usine indique où nous voulons aller en matière de normalisation. 

Les humains aussi peinent à assurer la cohérence d'une application à l'autre. Sans une norme clairement définie, deux développeurs humains différents prendront un éventail de décisions qui façonnent l'expérience. Pour un produit logiciel distinct, cette singularité peut être un atout. Au gouvernement, c'est surtout un handicap. Le gouvernement accorde une grande valeur à une expérience utilisateur positive et à la créativité qui résout un problème inédit, et pourtant la reproductibilité, la sécurité, la convivialité et l'accessibilité comptent bien plus qu'un caractère distinct et sur mesure. À travers des milliers de services destinés au public, un écart par rapport à l'apparence commune est déroutant plutôt que charmant.

Au fil de décennies de développement et au gré des ministères, l'expérience utilisateur a dérivé. Les applications individuelles visent la cohérence au sein de la base de code, mais à l'échelle du parc technologique, il existe une diversité importante qui devient déroutante pour les utilisateurs. Pour une personne qui cherche des services sociaux et qui utilise un lecteur d'écran ou une autre technologie d'assistance, cette incohérence fait la différence entre obtenir de l'aide et abandonner. La norme doit rejoindre le public là où il se trouve. 


La livraison assistée par l'IA peut aggraver le problème, car chaque prototype vibe-codé tend à être différent à moins qu'une norme claire ne soit introduite dès la toute première étape. Cependant, l'IA peut aussi résoudre efficacement ce problème en définissant des normes universelles que chaque agent d'IA suit. Cela exige un dépôt central, lisible par la machine, de normes, de gabarits et d'exemples de code (comme une bibliothèque de composantes communes et réutilisables) qui sont définis et appliqués 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 à éliminer cette complexité au moyen d'une mise en œuvre pilotée par l'IA. À l'aide de notre approche axée sur les normes, nous rationalisons cette complexité en un ensemble clair et commun de normes lisibles par l'IA. Cela garantit une grande convivialité, assure l'accessibilité et rend l'expérience cohérente sur chaque interface qu'une personne doit utiliser. 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 Voici Pronghorn

L'Alberta a conçu la première version de Pronghorn (connue sous le nom de Pronghorn Red) comme une application React / Supabase à code source ouvert. Elle reposait initialement sur Lovable et était intégrée à Render.com et à des fournisseurs infonuagiques tiers pour l'intégration de bases de données. Elle prend en charge un éventail de modèles différents de Google, d'Anthropic et de SpaceXAI, et offre une suite d'outils assistés par l'IA qui soutiennent le cycle de vie du développement des applications. 


Plus récemment, l'Alberta a collaboré avec Microsoft Canada pour transposer Pronghorn Blue en une version remaniée, mieux alignée avec les environnements d'entreprise. Elle introduit la prise en charge des modèles d'OpenAI et tire parti de composantes de pile natives d'Azure, comme 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 sera développé et maintenu tout au long de l'année à venir pour y ajouter des fonctionnalités supplémentaires. Red demeure une bonne architecture de référence, mais n'est plus en développement actif. Les deux versions sont destinées à être déployées par n'importe quelle organisation dans son propre environnement infonuagique privé ou public. Les deux sont publiées sous la licence ouverte MIT pour une utilisation sans entrave. 


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

Un projet dans Pronghorn commence par un peu de métadonnées et un choix de modèles, et passe rapidement à un clavardage avec la plus récente IA. Le clavardage est familier, mais introduit une capacité de prototypage rapide. Les applications décrites apparaissent immédiatement dans le corps du clavardage, de sorte que les idées peuvent être élaborées plus rapidement. Une personne sans bagage technique, et sans endroit où héberger une application, peut décrire ce qu'elle veut et voir apparaître une maquette fonctionnelle en direct, prête à être partagée avec un client pour recueillir ses réactions. Vous pouvez conserver un nombre illimité de conversations en fil, cloner des conversations, et télécharger l'ensemble du clavardage. Soit dit en passant, nous répétons couramment que toute plateforme qui ne vous laisse pas emporter le contenu de votre clavardage est fondamentalement défaillante. Le contenu est votre propriété intellectuelle, et vous devez pouvoir le conserver, le sélectionner et le transmettre à un agent. Pronghorn permet cela.

Vient ensuite l'espace des artéfacts, où Pronghorn offre une fonctionnalité approfondie, car un agent ne vaut que par le contexte qu'on lui fournit. Les projets sont généralement amorcés avec un éventail d'artéfacts variés, comme des jeux de diapositives, des PDF, des documents Word et des pages Web, et l'espace des artéfacts intègre tout cela, indexé et prêt à être utilisé par l'IA. Pronghorn vous permet de générer et d'analyser des images, de sorte qu'une maquette d'interface utilisateur peut être créée avec un modèle d'image et raffinée sur place. Vous pouvez modifier n'importe quel artéfact en collaboration avec un éditeur d'IA qui conserve un historique immuable de chaque changement, de sorte qu'un document de tout type peut être rédigé et révisé rapidement, avec un véritable contrôle de version, un traitement des images et des PDF, et une gestion de fichiers soignée.

À partir de vos clavardages et des artéfacts, Pronghorn construit les exigences d'affaires. Pointez-le vers le matériel, et il parcourt une hiérarchie agile et structurée : les épopées au sommet, puis les fonctionnalités qu'elles contiennent, puis les récits utilisateurs, et les critères d'acceptation qui indiquent quand chaque récit est terminé. Le résultat est une carte à quatre niveaux que vous pouvez développer, suivre et transmettre, ancrée dans les documents à partir desquels le projet a réellement commencé plutôt que dans le souvenir qu'une personne a d'une réunion.


## §07 Le canevas d'architecture

La fonctionnalité qui nous enthousiasme le plus à long terme est un canevas visuel partagé, bâti sur React Flow, où vous glissez-déposez les parties de l'architecture d'une application et travaillez dessus aux côtés d'agents d'IA qui peuvent à la fois lire le canevas et y dessiner. Une application moderne comporte de nombreuses couches : le nuage où elle s'exécute, le pare-feu, le frontal, le serveur, les API tierces, les bases de données et les intégrations internes. Tracées sous forme d'architecture fonctionnelle, cela représente des dizaines ou des centaines de composantes reliées en un seul diagramme. Dans Pronghorn, vous pouvez générer une architecture théorique au départ, vous y arrêter, et conserver des copies versionnées qui décrivent l'ensemble de l'application avant qu'aucun code n'existe.

Cela importe parce que c'est une autre façon d'empêcher qu'une interface ne soit vibe-codée jusqu'à l'existence. À la place de la production longue et verbeuse d'un modèle de langage, le canevas est une description compacte et resserrée : une hiérarchie claire de nœuds reliés par des arêtes étiquetées, avec des métadonnées sur chacun indiquant ce qu'il fait et comment il se connecte. C'est le bon point de départ pour la construction, et il peut être téléchargé et remis directement à un agent de codage. La forme d'une application d'entreprise est une décision à prendre délibérément, dès le départ, plutôt qu'une décision à laisser aux choix qu'un modèle imprévisible fait au fur et à mesure. Le canevas est l'architecture fonctionnelle, qui est elle-même une exigence, une exigence non fonctionnelle. Jumelez les exigences fonctionnelles de la section des exigences à l'architecture du canevas, et vous obtenez une spécification complète qui indique clairement comment l'application devrait fonctionner.


## §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 construction. Un rédacteur d'analyse de rentabilisation, un rédacteur de charte et de demande de propositions, un planificateur de projet et un constructeur d'échéancier lisent vos clavardages, vos artéfacts et vos canevas, et produisent un plan de projet prêt à être présenté à un client pour obtenir son adhésion. Vous pouvez modifier ces agents, créer les vôtres et les organiser en un flux de travail qui transforme une idée embryonnaire en l'ensemble complet d'artéfacts dont un projet a besoin pour démarrer.

Pronghorn comprend aussi des agents de codage et un agent de base de données, des moyens rapides de faire passer une idée à l'échelle : importer des données déjà en JSON ou en CSV, se connecter à un éventail de bases de données, et travailler avec une base de données Postgres hébergée sur Azure, Render, AWS ou ailleurs, avec un déploiement pratique dans Azure et render.com dans l'édition Red. Ces fonctionnalités de construction et de déploiement résident désormais plus pleinement dans l'étape suivante de l'usine, Nexus, qui ajoute les contrôles de sécurité et l'observabilité des agents que Pronghorn n'a jamais été conçu pour porter.


## §09 Le premier tiers de l'usine

Pronghorn est la première phase critique : recherche et idéation, développement de l'architecture et cartographie des exigences. Placé aux côtés des propres exigences, documents et 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 écouteur dans Claude Code peut surveiller les changements dans un projet Pronghorn, et une API permet à n'importe quelle plateforme de codage agentique d'y réécrire, de sorte qu'un agent peut être un contributeur de premier ordre, ajoutant à l'architecture, aux exigences et aux artéfacts. À partir de Nexus, les deux se relient dans les deux sens, et le développement est piloté à partir de là.

Un mot à nos constructeurs. La tentation, dans le développement agentique, est de commencer tout de suite à construire l'application. C'est satisfaisant, cela vous permet de tester une idée rapidement, et c'est aussi ainsi qu'on se retrouve avec une architecture mal alignée avec la pile technologique que vous devez utiliser. Pronghorn est l'endroit où le personnel technique et non technique s'entend sur la portée, les plans et les exigences avant que cela ne se produise. Rien n'y est verrouillé; les artéfacts se détachent proprement et passent directement à la construction. Sautez cette étape à vos risques et périls, sinon vous livrerez des applications qui ont l'air correctes, qui suivent les normes communes, et qui se comportent quand même comme une expérience irrégulière et inégale en dessous, surtout à 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