Le développeur OutSystems construit des applications web Reactive et mobiles dans Service Studio, ou dans ODC Studio. Il modélise les entités, écrit la logique en actions client et serveur, branche des API REST ou SOAP et déploie avec LifeTime. Deux plateformes coexistent : OutSystems 11, installée chez beaucoup d'entreprises, et ODC (OutSystems Developer Cloud), native cloud, où les modules deviennent des applications et des bibliothèques. Les annonces disent développeur, consultant ou tech lead OutSystems.
La logique visuelle cache le SQL et le réseau. Un candidat qui a suivi les parcours de formation produit vite des écrans, sans toujours savoir ce que coûte un agrégat ou ce qu'expose une action serveur appelée depuis le navigateur. La certification Associate Developer existe pour O11 et pour ODC ; les spécialisations Web, Mobile, Architecture et Security vont plus loin.
Partez d'une application que le candidat a livrée : son découpage en modules, un écran lent qu'il a corrigé, une intégration difficile. Le PDF contient un cas de 20 minutes sur une application de demandes d'achat.
La plateforme OutSystems, vue par le développeur
OutSystems 11 et ODC
OutSystems 11 (O11) est la plateforme historique, installée sur site ou dans le cloud d'OutSystems. ODC, OutSystems Developer Cloud, est la plateforme native cloud : applications et bibliothèques indépendantes, déploiement depuis le Portal, base PostgreSQL. Beaucoup de projets tournent encore en O11, et certaines entreprises préparent le passage à ODC.
Service Studio et ODC Studio
Les environnements de développement visuels. On y dessine les écrans, la logique sous forme de diagrammes, les entités et les intégrations. Le code est généré puis compilé à la publication. Un développeur expérimenté sait ce que produit la plateforme derrière chaque élément visuel.
Entités, agrégats et nœuds SQL
Les entités sont les tables, les agrégats des requêtes construites visuellement. Pour les requêtes complexes, le nœud SQL permet d'écrire le SQL directement. La performance d'une application OutSystems se joue surtout sur la façon dont ces requêtes sont écrites.
Actions client, actions serveur et écrans Reactive
En Reactive Web et en mobile, une partie de la logique tourne dans le navigateur ou sur le téléphone, l'autre sur le serveur. La frontière entre les deux décide de la performance et de la sécurité, et c'est là que les erreurs de débutant se concentrent.
Intégrations REST, SOAP et code étendu
La plateforme consomme et expose des API REST et SOAP. Quand la logique visuelle ne suffit pas, on écrit du C# : extensions avec Integration Studio en O11, bibliothèques externes avec l'External Libraries SDK en ODC.
Timers, processus et workflows
Les timers lancent des traitements planifiés, les processus BPT et les light processes des traitements déclenchés par des événements en O11. En ODC, les workflows remplacent les processus. Les traitements de masse et les appels lents passent par ces mécanismes.
LifeTime et ODC Portal
LifeTime gère les environnements O11 et déploie les applications de l'un à l'autre en vérifiant les dépendances. En ODC, le Portal fait ce travail, application par application, d'un stage au suivant. Les Site Properties d'O11 s'y appellent des Settings.
Code Quality, Forge et Mentor
Code Quality, l'ancien AI Mentor Studio, analyse le code et classe les constats en architecture, performance, sécurité et maintenabilité. La Forge propose des composants partagés par la communauté. En ODC, Mentor génère des applications par l'IA et l'AI Agent Builder crée des agents.
Le développeur OutSystems travaille près des utilisateurs métier, avec des cycles de livraison courts. Selon le poste, il construit de nouvelles applications, reprend un portefeuille existant dont l'architecture a dérivé ou prépare une migration vers ODC. Les profils viennent souvent du développement .NET ou Java, parfois de la formation OutSystems directement. Précisez dans l'offre la plateforme (O11 ou ODC), la part d'applications mobiles et le niveau d'intégration avec les autres systèmes.
Six points à valider chez un développeur OutSystems
- Modélisation des données et agrégats
- Logique client et serveur en Reactive
- Architecture des modules et dépendances
- Intégrations REST, SOAP et code étendu
- Traitements asynchrones et performance
- Déploiement, sécurité et passage à ODC
Écrans, modules, intégrations : cinq questions OutSystems
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un écran de liste met huit secondes à s'afficher. L'agrégat joint quatre entités sans limite de lignes. Que vérifiez-vous ?
Une bonne réponseLe nombre de lignes ramenées : Max Records réglé sur la taille de la page et une pagination côté serveur. Les filtres placés dans l'agrégat et non appliqués ensuite sur la liste, avec des index sur les attributs filtrés et triés. Le type de jointure (Only With ou With or Without) choisi selon le besoin. Les autres agrégats de l'écran et ceux qui attendent le résultat d'un premier. Il lit le SQL généré et, en O11, les requêtes lentes dans Service Center.
Signal d'alerte« Il faut un serveur plus gros », ou tout ramener dans l'écran puis filtrer côté client avec une boucle ou ListFilter.
Question 2 · junior à confirmé
Dans une application Reactive, quelle différence faites-vous entre une action client, une action serveur et une Data Action ?
Une bonne réponseL'action client s'exécute dans le navigateur. L'action serveur s'exécute sur le serveur ; appelée depuis une action client, elle devient une requête que n'importe qui peut appeler, donc elle vérifie elle-même les droits et les entrées. La Data Action récupère des données pour l'écran avec une structure en sortie, au chargement ou à la demande, comme un agrégat. Il évite d'enchaîner plusieurs appels serveur depuis une action client et regroupe la logique dans une seule action serveur.
Signal d'alerte« C'est pareil », ou une vérification de rôle faite seulement côté client en masquant un bouton.
Question 3 · confirmé
Votre application compte quarante modules, et publier un module de base oblige à republier la moitié des autres. D'où vient le problème ?
Une bonne réponseD'une architecture qui ne respecte pas le canvas : références vers le haut (un module Core qui dépend d'un module End-user), références latérales entre modules End-user, cycles entre modules Core, écrans et logique métier mélangés dans les mêmes modules. Il propose de séparer les services métier, de descendre ce qui est réutilisable en Foundation et de couper les cycles. Il connaît les Service Actions, qui créent une dépendance faible. Il visualise les dépendances avec Discovery ou les constats d'architecture de Code Quality.
Signal d'alerte« C'est normal, on republie tout », ou une réponse qui ne parle jamais de sens des dépendances.
Question 4 · confirmé
Vous consommez une API REST externe qui répond parfois en 30 secondes ou renvoie une erreur 500. Comment l'intégrez-vous ?
Une bonne réponseLa méthode consommée a un timeout réglé. Les en-têtes d'authentification et la journalisation passent par les callbacks OnBeforeRequest et OnAfterResponse. L'appel se fait côté serveur, jamais depuis le navigateur, avec la clé d'API stockée dans un paramètre côté serveur. Les erreurs sont attrapées dans l'action appelante, avec un nombre de tentatives limité. Un appel lent sort du chargement de l'écran : il part dans un traitement asynchrone, timer, processus ou workflow selon la plateforme, et l'écran affiche un état d'attente.
Signal d'alerteUn appel lancé au démarrage de l'écran sans timeout, ou la clé d'API placée dans une action client ou une variable client.
Question 5 · confirmé
Chaque nuit, un timer doit traiter 500 000 enregistrements, et il s'arrête au bout de 20 minutes. Comment le réécrivez-vous ?
Une bonne réponseIl reconnaît le timeout du timer, de 20 minutes par défaut en O11. Il découpe le traitement en lots, enregistre la progression (dernier identifiant traité ou indicateur sur la ligne), valide la transaction après chaque lot avec CommitTransaction, surveille le temps écoulé et relance le timer lui-même avant la limite. Il ne charge pas les 500 000 lignes en mémoire, et passe par un nœud SQL pour une mise à jour en masse quand la logique le permet.
Signal d'alerteMonter le timeout à dix heures et tout traiter dans une seule transaction.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Questions fréquentes sur le recrutement d'un développeur OutSystems
OutSystems 11 ou ODC : faut-il exiger la plateforme de votre projet ?
La logique visuelle, les agrégats et les écrans Reactive sont communs aux deux. Un développeur O11 confirmé s'adapte à ODC, à condition de comprendre les changements : applications et bibliothèques au lieu de modules, entités publiques en lecture seule, workflows à la place des processus, bibliothèques externes au lieu des extensions. Pour une migration, cherchez quelqu'un qui connaît bien les deux. Pour un projet neuf en ODC, une expérience O11 solide suffit souvent.
Un développeur .NET ou Java peut-il devenir développeur OutSystems ?
Oui, et ces profils sont fréquents. Ils comprennent vite ce que la plateforme génère, écrivent un bon SQL et des extensions propres. Le risque inverse existe : vouloir tout coder en C# au lieu d'utiliser les mécanismes de la plateforme. Demandez comment ils feraient une tâche donnée en OutSystems pur, puis à quel moment ils passeraient au code étendu. La certification Associate Developer leur demande en général quelques semaines de préparation.
Les certifications OutSystems suffisent-elles à juger un candidat ?
L'Associate Developer montre que la personne connaît la plateforme et ses composants. Les spécialisations, en particulier Architecture et Security, demandent davantage. Aucune ne montre la tenue d'une application en production : écran lent corrigé, déploiement bloqué résolu, timer qui échoue la nuit. Vérifiez sur quelle plateforme porte la certification, O11 ou ODC, et faites raconter des situations réelles.
Quel test technique proposer à un développeur OutSystems ?
Un environnement de test avec une petite application déjà construite et volontairement mal faite : un agrégat sans limite, un contrôle de rôle seulement côté client, une référence entre modules End-user. Le candidat trouve et corrige les problèmes en une heure, en expliquant ses choix. Vous voyez sa lecture du code existant, ce qui compte sur la plupart des postes. Un écran à construire de zéro montre moins de choses.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
