Architecture OutSystems ODC : guide complet des artefacts et applications

Temps de lecture : 16 min

Fondamentaux de l’architecture ODC

L’architecture OutSystems ODC (OutSystems Developer Cloud) a été pensée pour simplifier le cycle de vie des applications par rapport à la version O11. Concrètement, elle se rapproche des concepts que l’on retrouve dans Kubernetes : chaque application devient un conteneur autonome, facilitant la scalabilité, la performance et l’interopérabilité. Plus précisément, on crée aujourd’hui des applications web responsives, des applications mobiles (natives ou PWA), des agents intelligents avec intégration LLM, des workflows, et des bibliothèques de composants réutilisables.

Types d’applications en ODC

Dans l’univers ODC, les types d’applications disponibles sont clairs :

• Applications web : interfaces responsives pour tous les navigateurs modernes.
• Applications mobiles : optimisées pour smartphones et tablettes, en natif ou en PWA.
• Agents : logiciels intelligents dotés d’IA générative, capables d’exécuter des tâches de manière autonome.
• Workflows : processus répétitifs exécutés séquentiellement, déclenchés par des événements.
• Bibliothèques : ensembles de composants logiques et d’IU conçus pour la réutilisabilité.

Structure interne des applications

Contrairement à O11, une application en ODC n’est plus un simple conteneur de modules. Elle devient le dépôt de code d’un domaine métier complet. Par exemple, si vous développez un système de gestion client, tous les écrans, blocs, API et logiques associés au client se trouveront dans la même application. Bien qu’on puisse craindre un monolithe, la règle est simple : ne regrouper que ce qui appartient au même concept métier. Cela centralise le développement, accélère les déploiements et élimine la complexité des mises à jour de consommateurs (références faibles).

Section Événements

Deux types d’artéfacts sont disponibles :

• Timers : exécution asynchrone de code à des intervalles définis, identiques aux timers d’O11.
• Événements : propres à ODC, ils notifient les abonnés d’une occurrence sans avoir besoin de connaître leur implémentation. Ils restent privés à l’application.

Section Interface

Les artéfacts suivants sont disponibles, certains publics (référençables) et d’autres privés :

• Écrans web : visibles par l’utilisateur final, potentiellement publics (référence faible).
• Site externe : permet de rediriger vers une URL externe, non public.
• Bloc : contenu réutilisable au sein d’une seule application, privé.
• Image : ressource visuelle privée.
• Thèmes : feuilles de style CSS, privées dans une application (publiques seulement dans une bibliothèque).
• Scripts : fichiers JavaScript, toujours privés.

Section Logique

• Action client : logique exécutée côté navigateur, privée.
• Action serveur : logique exécutée côté serveur, privée.
• Action service : logique serveur en transaction isolée, toujours publique (référence faible).
• REST : intégration ou exposition d’API REST. Les méthodes exposées sont publiques pour le réseau, les méthodes consommées sont privées.
• Rôles : contrôle d’accès, public.
• Exceptions : gestion d’erreurs, privées.

Section Données

• Entités dynamiques : tables de base de données avec CRUD complet.
• Entités statiques : données d’énumération définies en conception, modifiables uniquement en développement.
• Structures : structures de données en mémoire.
• Paramètres (Settings) : valeur paramétrable, analogue aux propriétés de site d’O11.
• Variables client : variables côté navigateur.
• Ressources multilangues si l’application est traduite.

Les bibliothèques dans ODC

Les bibliothèques sont conçues pour la réutilisabilité maximale. Elles ne contiennent pas d’événements (pas de section Événements). Leurs artéfacts sont sensiblement les mêmes que ceux des applications, mais avec quelques différences :

• Blocs : peuvent être publics.
• Images : peuvent être partagées.
• Thèmes : publics par défaut.
• Actions client/serveur : peuvent être déclarées publiques.
• REST : uniquement consommation d’API, méthodes privées.
• Exceptions : privées.

Les bibliothèques offrent une fonctionnalité puissante : le versioning. Vous pouvez choisir la version d’une bibliothèque utilisée par chaque consommateur, ce qui facilite la gestion des changements majeurs sans rupture.

Flux de réutilisation entre applications et bibliothèques

Les bibliothèques contiennent des concepts génériques, non fonctionnels. Les applications embarquent la logique métier. Les flux de réutilisation possibles :

• Application -> Application (référence faible)
• Application -> Système externe
• Application -> Bibliothèque (référence forte)
• Bibliothèque -> Système externe

Les références faibles impliquent que le code du producteur vit dans un conteneur séparé de celui du consommateur. Si les signatures des éléments consommés ne changent pas, aucun rafraîchissement n’est nécessaire. Les références fortes (bibliothèque consommée par une application) placent le code de la bibliothèque dans le même conteneur que le consommateur.

Applications agentiques et workflows

Applications agentiques (Agentic Apps)

Une application agentique utilise un ou plusieurs agents IA pour exécuter des tâches, automatiser des workflows ou gérer des processus complexes. Contrairement aux applications classiques, elles n’ont pas besoin d’intervention utilisateur à chaque étape. L’agent est invoqué via une Action Service dédiée, avec entrée utilisateur et ID de session, et retourne une réponse en JSON.

Workflows

Les workflows en ODC sont proches des BPT d’O11, mais lancés par des événements. Un workflow expose des artéfacts comme Start, End, Activité automatique, Activité humaine, Aller à une étape, et Décision. Il communique via des événements et des Actions Service. Attention : les workflows sont uniquement consommateurs, jamais producteurs. Ils utilisent toujours des références faibles pour les éléments des applications (événements, actions service, écrans web).

Nommer applications et artéfacts

Avec la disparition des modules, les suffixes de noms ne sont plus nécessaires. Le nom de l’application doit refléter le domaine métier qu’elle représente. Il fait partie de l’URL, donc doit être clair et utilisateur. Les bibliothèques, en revanche, n’affectent pas les URLs, et leurs noms doivent indiquer leur objectif (exemple : Web Theme Bootstrap).

Processus de conception architecturale (DOA)

Phase 1 : Découverte

Dans cette phase, on identifie tous les besoins fonctionnels et non fonctionnels. Les questions clés :

• Quels concepts métier couvre l’application ?
• Qui sont les parties prenantes et sponsors ?
• Assurer l’indépendance des équipes.
• Relever les besoins non fonctionnels (sécurité, performance, intégrations).
• Identifier les composants réutilisables et intégrations externes.

Phase 2 : Organisation

On regroupe les concepts métier en clusters à forte cohésion, en s’appuyant sur les experts du domaine. Il est crucial d’impliquer toutes les parties prenantes avec un langage commun, en évitant excès de jargon technique. Cette phase peut être itérée avec la phase de découverte pour affiner les groupements.

Phase 3 : Assemblage

Les clusters sont mappés aux applications ODC. L’objectif : indépendance des cycles de livraison, claire propriété des applications, réduction de la complexité. À l’issue, on obtient le Blueprint architectural : un schéma simple montrant l’application et ses dépendances.

Bonnes pratiques et pièges à éviter

Évitez de créer des monolithes en vous en tenant strictement à la règle du domaine unique. Veillez à ce que chaque application ait une propriété claire et un rythme de déploiement autonome. Utilisez les bibliothèques pour les aspects transversaux (thèmes, connecteurs, helpers) et nettoyez les dépendances inutiles entre applications. N’oubliez pas : toute architecture est un compromis. Acceptez les trade-offs lorsque nécessaire.

Conclusion : architecture pensée pour le métier

L’architecture ODC place le métier au centre, en supprimant les frictions techniques d’O11. Applications, bibliothèques, agents et workflows forment un écosystème où la scalabilité et la maintenabilité sont renforcées. Le processus DOA garantit une conception robuste, avec un blueprint simple à comprendre et à faire évoluer.