Développement d'applications full stack avec IRIS Backend

Comment j'ai utilisé le vibecoding pour un backend (et un frontend) sur InterSystems IRIS

Je souhaitais essayer le vibecoding sur une configuration réelle de backend et de frontend sur InterSystems IRIS, en utilisant idéalement un cas concret plutôt qu'un simple exemple théorique. L'objectif était simple : prendre un package persistant existant et bien connu dans IRIS et créer rapidement une interface utilisateur et une API fonctionnelles autour de celui-ci, en laissant l'IA se charger autant que possible des tâches répétitives. Voici le résultat de ces expériences.

Choix du modèle de données

Pour cette expérience, j'ai choisi la version de démo Samples BI. Elle est idéale pour le vibecoding ::

• Elle contient plusieurs classes persistantes bien conçues
• Elle est très connue et facile à installer
• Elle fonctionne déjà très bien avec IRIS BI

Son installation est un jeu d'enfant grâce à IPM :

zpm "install samples-bi-demo"

Une fois l'installation terminée, j'ai vérifié si IRIS BI fonctionnait correctement. Pour plus de commodité et une meilleure expérience de navigation, j'ai également installé DSW (DeepSee Web). et je me suis assuré que les données étaient bien présentes et que tout fonctionnait parfaitement. Voici une capture d'écran des données installées telles qu'elles s'affichent dans DSW :

La version Démo Sampels Bi présente les ventes d'une entreprise fictive,  HoleFoods, qui fabrique et commercialise des produits portant le logo « Holes ». Cette configuration s'appuie sur  l'ensemble de classes persistantes de :

• Produit
• Point de vente
• Pays
• Région
• Transaction

Cela correspond tout à fait à une démonstration CRUD.

Configuration de Vibecoding

Vous trouverez ci-dessous ma configuration « Vibecoding avec IRIS » :

• VS Code

  • Extension ObjectScript d'InterSystems
  • plugin OpenAI Codex

• Docker

• Un modèle de projet ObjectScript très basique provenant d'Open Exchange

Et c'est tout. Pas d'infrastructure lourde, pas de frameworks personnalisés.

La recette de l'interface utilisateur

L'architecture que j'ai suivie est simple et reproductible :

1. Une interface utilisateur frontend
2. Communication avec IRIS via une API REST
3. Définie par une spécification Swagger (OpenAPI)
4. Mise en place nativement dans InterSystems IRIS ObjectScript et IRIS SQL.

Génération de l'API Swagger

Dans cette approche, la spécification OpenAPI ou Swagger sert d'intermédiaire compris à la fois par l'interface utilisateur frontend et par IRIS. IRIS 2025.3 prend en charge Swagger / OpenAPI 2.0 ; ainsi, j'ai demandé à Codex de générer une API de type CRUD pour l'une des classes persistantes, en commençant par Produit. Afin de faciliter la tâche de l'IA, j'ai exporté le code source des classes persistantes depuis mon instance IRIS locale et je l'ai partagé avec Codex.

J'ai décidé de commencer par une exigence simple :

Une page permettant de créer, modifier, afficher la liste et supprimer des Produits

Pour y parvenir, j'ai demandé à Codex de :

• Générer une définition Swagger spec.cls
• Faire en sorte que l'objet Product dérive de %JSON.Adaptor
• Respecter les conventions et les préférences décrites dans mon fichier AGENTS.md (il s'agit essentiellement d'un ensemble de "bonnes pratiques" issues d'interactions précédentes)

J'ai également choisi un chemin d'accès basique pour l'API :

/holefoods/api

Codex a généré la classe :

Holefoods.api.spec Après l'avoir compilée, IRIS a automatiquement produit deux classes supplémentaires :

• Holefoods.api.disp Elles sont toujours générées par IRIS et chargées du routage des points de terminaison ainsi que du traitement des requêtes/réponses
• Holefoods.api.impl La logique métier proprement dite y est implémentée ; elle contient initialement des stubs de méthodes.

C'est l'une de ces fonctionnalités d'IRIS qui semble presque magique lorsqu'elle est associée au vibecoding. Prévoyant (ou peut-être prudent 😄), Codex a demandé:

• L'application web devait-elle être enregistrée dans module.xml
• Quel nom de classe de répartition devait être utilisé

J'ai confirmé ces deux points, ce qui signifie que l'API est créée automatiquement au démarrage d'IRIS. De plus, la configuration de l'application web a été ajoutée dans le fichier module.xml de sorte que l'application web apparaîtra dans IRIS lors de la prochaine compilation Docker ou lors du chargement manuel du module :

<CSPApplication
Url="/holefoods/api"
DispatchClass="HoleFoods.api.disp"
MatchRoles=":{$dbrole}"
PasswordAuthEnabled="0"
UnauthenticatedEnabled="1"
Recurse="1"
UseCookies="2"
CookiePath="/holefoods/api/"
CorsAllowlist="*"
CorsCredentialsAllowed="1"
CorsHeadersList="Content-Type,Authorization,Accept-Language,X-Requested-With,session"
/>

Configuration de sécurité

Quiconque a déjà travaillé avec IRIS sait que les applications web et la sécurité peuvent parfois s'avérer… mouvementées. J'ai donc expressément demandé à Codex de générer :

Holefoods.api.security.cls

, selon les instructions fournies dans AGENTS.md

Cette classe a introduit les ajustements de sécurité nécessaires pour permettre à la phase de développement de l'API de se dérouler sans heurts, tout en étant clairement et facilement évolutive vers n'importe quel niveau de sécurité supérieur. Elle se concentre principalement sur toutes les relations de sécurité liées à un rôle spécifique attribué à une application et donc appliqué à toute personne connectée à cette application.

Mise en œuvre de l'API

Étape suivante : la mise en œuvre.

J'ai demandé à Codex d'implémenter intégralement la logique CRUD dans :

Holefoods.api.impl Et c'est exactement ce qu'il a fait. À cette étape, tout était prêt pour passer aux tests.

Tests avec Swagger UI

Pour valider rapidement l'API, j'ai installé Swagger UI :

zpm "install swagger-ui"

Remarque importante (appris à mes dépens auparavant) : L'interface utilisateur Swagger nécessite un point de terminaison _spec, qui doit toujours être implémenté dans la classe impl. Cela étant fait, l'interface utilisateur Swagger fonctionne parfaitement.

Après avoir redémarré IRIS, la définition complète de l'API s'est affichée, et j'ai pu la tester de manière interactive.

La requête:

GET /holefoods/api/products

a renvoyé des données pertinentes. À ce stade, le backend était pour l'essentiel "achevé".

Développement du frontend

Avec une API opérationnelle et une spécification Swagger bien conçue, la création du frontend devient un jeu d'enfant. Plusieurs options s'offrent à vous :

• Demander à Codex de générer le frontend
• Utiliser des outils tels que Lovable pour créer une structure d'interface utilisateur directement à partir de la spécification

J'ai choisi cette dernière option — et au bout de quelques minutes, je disposais d'une interface utilisateur locale fonctionnelle connectée à IRIS. Après quelques tests (et la correction d'un petit problème lié à la suppression), l'expérience complète de bout en bout était en place : IU → API → IRIS → stockage persistant. Voici la capture d'écran du premier résultat (elle est disponible localement à l'adresse suivante http://localhost:5174/ ):

Ajout de tests unitaires (comme le font tous les adultes)

La dernière pièce manquante était les tests unitaires. J'ai demandé à Codex de générer :

HoleFoods.api.Unittests.cls

pour couvrir tous les points de terminaison définis dans la spécification Swagger.

Une fois générée, j'ai ajouté la classe de test à la configuration du module afin que les tests puissent être exécutés via IPM à l'aide de la ligne suivante

<UnitTest Name="/tests" Package="HoleFoods.api.tests" Phase="test"/>

ainsi, les tests peuvent être appelés comme suit :

zpm "test esh-vibe-back-demo" 

Et voilà, tous les points de terminaison de l'API étaient couverts et visibles dans le portail de tests unitaires IRIS :

Par la suite, j'ai demandé d'ajouter le point de terminaison /transactions. Codex a intégré le code dans la classe de spécification, a développé la mise en œuvre dans impl et a mis en place des tests unitaires. Il a également développé une interface utilisateur dont vous pouvez voir le résultat ici :

Conclusions

La combinaison InterSystems IRIS + Swagger + vibecoding semble être une combinaison puissante et efficace.

Bien sûr, le résultat est un prototype — mais un prototype presque réel et testable, développé extrêmement vite.

Voici le dépôt.

L'utilisation d'AGENTS.md et la mise en œuvre d'exemples open source suivant les meilleures pratiques pour gérer le backend IRIS peuvent renforcer les capacités d'IRIS en tant que backend robuste pour des applications full-stack complètes.

La fonction de génération de code personnalisable offerte par OpenAI Codex ou Claude Code ouvre la voie à la création de backends ultra-performants sur IRIS, car tout SQL sur un backend IRIS n'est rien d'autre qu'une génération de code à partir de la traversée des globales. 

P.S.

Cet article a été rédigé par un humain et relu par l'IA pour améliorer la qualité de la langue anglaise :)

P.P.S.

Et en bonus, l'interface utilisateur a également été développée sur Lovable ; vous pouvez donc vous amuser avec la version démo en ligne :