Développement de logiciels APEX : le guide Oracle APEX 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Le développement de logiciels APEX consiste à créer des applications web métier avec Oracle APEX (Application Express), une plateforme low-code intégrée à Oracle Database. Sur le marché américain, l’expression désigne presque toujours Oracle APEX, et non Apex, le langage de programmation de la plateforme Salesforce ; les deux partagent un nom et rien d’autre, et la section comparative ci-dessous les distingue dans un seul tableau.

La plupart des organisations n’arrivent pas à APEX parce qu’elles veulent un nouvel outil. Elles y arrivent parce qu’un parc Oracle Forms vieillit, qu’une mise à niveau de WebLogic approche ou que des processus critiques reposent sur des tableurs et des bases Access dont personne ne veut assumer la responsabilité. APEX est donc une décision de modernisation avant d’être une décision d’outillage, et c’est pourquoi les équipes qui proposent des services de modernisation d’applications existantes commencent généralement par un inventaire de l’existant, des données qui comptent et des écrans qui peuvent être supprimés, avant de choisir entre APEX, du code sur mesure ou une combinaison des deux.

Ce guide présente ce qu’est Oracle APEX et comment il fonctionne, ce qui a changé avec les versions 26.1 et 26.2 de 2026, les cas d’usage typiques, le contenu des services de développement, le processus de livraison étape par étape, la migration d’Oracle Forms vers APEX, une comparaison avec d’autres plateformes low-code et le code sur mesure, les coûts, les cas où APEX n’est pas le bon choix, la sécurité, ainsi qu’une checklist pour choisir une société de développement Oracle APEX.

Qu’est-ce que le développement de logiciels APEX ?

Le développement de logiciels APEX consiste à créer des applications web sur Oracle APEX, une plateforme low-code où pages, formulaires, rapports, graphiques et workflows sont assemblés de manière déclarative et stockés sous forme de métadonnées dans Oracle Database. La logique métier est écrite en SQL et en PL/SQL, les langages propres à la base de données, et les développeurs n’ajoutent du JavaScript, du CSS ou des appels REST que lorsque les composants déclaratifs ne suffisent pas.

Oracle APEX s’appelait auparavant Oracle Application Express, et c’est une fonctionnalité sans coût d’Oracle Database depuis 2004. Selon la page produit d’Oracle, il n’existe aucun frais distinct par développeur, par application ou par utilisateur final : si vous disposez d’une Oracle Database prise en charge, vous pouvez y créer et y exécuter des applications APEX. Ce modèle tarifaire est l’une des principales raisons pour lesquelles le développement Oracle APEX est répandu dans les organisations qui paient déjà pour Oracle.

Une application APEX typique se compose de quelques briques que tout développeur Oracle reconnaît :

• Interactive Reports et Interactive Grid pour des tableaux de données consultables, filtrables et modifiables.
• Formulaires et assistants générés à partir de tables ou de vues, avec validations et calculs.
• Dynamic Actions qui ajoutent un comportement côté client (afficher, masquer, rafraîchir, appeler du PL/SQL) sans JavaScript écrit à la main.
• Graphiques, calendriers, cartes et recherche à facettes pour les tableaux de bord et l’exploration en libre-service.
• Validations, workflows et automatisations pour les processus métier en plusieurs étapes et les tâches planifiées.
• Sources de données REST et REST-enabled SQL pour consommer et exposer des API.

Comment Oracle APEX fonctionne sous le capot

Oracle APEX n’a pas de niveau serveur d’applications distinct : la définition de l’application est stockée sous forme de métadonnées dans des tables de la base, et Oracle REST Data Services (ORDS) joue le rôle d’écouteur web qui transmet les requêtes du navigateur au moteur APEX dans la base de données. Lorsqu’un utilisateur ouvre une page, le moteur lit la définition de la page, exécute le SQL et le PL/SQL qu’elle référence, puis renvoie le HTML au navigateur via ORDS.

Cette architecture a des conséquences pratiques. Les données ne quittent jamais la base pour être traitées dans un niveau intermédiaire, de sorte que les écrans riches en données sont rapides et que le modèle de sécurité de la base s’applique à chaque requête. Le déploiement est plus simple, car il n’y a pas de serveur d’applications Java ou .NET à patcher, et une application peut être exportée, versionnée et importée comme un tout. La contrepartie est un couplage fort : une application APEX est, par conception, une application Oracle Database.

Qui développe avec APEX

APEX est principalement utilisé par trois groupes : les développeurs PL/SQL et base de données qui connaissent déjà le modèle de données, les directions informatiques centrées sur Oracle qui doivent livrer rapidement des outils internes, et les citizen developers côté métier qui travaillent sous la gouvernance de l’IT. Le point commun est SQL. Un développeur qui écrit du bon SQL et du bon PL/SQL peut devenir productif sur APEX en quelques semaines, tandis qu’un développeur front-end sans expérience des bases de données trouvera la courbe d’apprentissage plus raide que ne le laisse penser l’étiquette « low-code ».

Pour les systèmes de production, les équipes les plus efficaces associent des spécialistes APEX à un expert en performance des bases de données et, lorsque l’interface compte, à un développeur front-end qui maîtrise l’Universal Theme. Les citizen developers sont productifs pour les prototypes et les outils de service, mais les applications d’entreprise exigent toujours revue de code, tests et plan de mise à niveau, comme n’importe quel autre logiciel.

Oracle APEX ou Salesforce Apex : de quel « APEX » parle-t-on ?

Oracle APEX est une plateforme low-code pour créer des applications web sur Oracle Database, tandis que Salesforce Apex est un langage de programmation propriétaire à typage fort destiné à la logique métier sur la plateforme Salesforce. Les résultats de recherche pour « apex software development » mélangent les deux, ainsi que des entreprises sans rapport nommées Apex ; il vaut donc la peine de vérifier lequel désigne réellement une offre d’emploi, un prestataire ou une proposition commerciale.

Si votre projet concerne en réalité Salesforce, notre guide des services de conseil Salesforce et la page consacrée à l’intégration Salesforce sont de meilleurs points de départ. La suite de cet article porte sur Oracle APEX.

Quoi de neuf dans Oracle APEX en 2026 (26.1 et 26.2) ?

Les versions 2026 orientent Oracle APEX vers une IA encadrée et un développement compatible avec git : la 26.1 a introduit APEXlang, les AI Agents et les AI Interactive Reports, et la 26.2 a rendu APEXlang utilisable fichier par fichier et relié APEX à Oracle Deep Data Security. Pour les équipes qui prévoient un nouveau développement APEX en 2026, ces deux versions changent la manière dont les applications sont versionnées, relues et sécurisées.

Selon l’annonce d’Oracle pour la 26.1, cette version est disponible sur site pour toutes les distributions d’Oracle AI Database (Exadata, Linux et Windows), les services OCI et multicloud suivant ensuite. Le partenaire d’Oracle Pretius décrit la 26.1 comme la première version majeure d’APEX depuis environ dix-huit mois et résume la vision d’Oracle d’une IA encadrée par la formule « If you generate it, you own it » (si vous le générez, vous en êtes responsable). Les détails de la 26.2 proviennent de l’annonce d’Oracle pour la 26.2 ; Oracle a republié les fichiers de téléchargement le 9 octobre 2026 et tient à jour une page des problèmes connus qu’il est utile de lire avant une mise à niveau.

APEXlang et gestion de versions

APEXlang transforme une application APEX en fichiers lisibles et versionnables, ce qui signifie que le travail sur APEX peut enfin suivre le même branching git, la même revue de code et le même pipeline CI/CD que le reste de vos logiciels. Avant APEXlang, les équipes exportaient une application entière sous la forme d’un seul gros script SQL : deux développeurs modifiant des pages différentes produisaient des exports en conflit, et les revues comparaient du code généré par la machine.

APEX 26.2 complète le tableau avec l’import au niveau du fichier : une page ou un composant partagé peut être exporté et importé sous forme de fichier .apx, et le builder peut comparer un fichier avec l’application et n’intégrer que les modifications. En pratique, plusieurs développeurs peuvent ainsi travailler en parallèle sur une même application, les diffs deviennent parlants dans les merge requests et un pipeline peut ne déployer que ce qui a changé. Pour une équipe de développement Oracle APEX, c’est le changement de processus le plus important de 2026.

AI Agents et AI Interactive Reports

Les AI Agents d’APEX sont des assistants qui n’agissent qu’au moyen d’outils explicitement approuvés par un développeur, et les AI Interactive Reports permettent aux utilisateurs de remodeler un rapport en langage naturel sur des données qu’ils sont déjà autorisés à voir. L’objectif de conception est une IA encadrée : le modèle propose, mais chaque action et chaque ligne de données passent par des contrôles APEX et base de données définis par l’équipe de développement.

APEX 26.2 a élargi le choix des modèles avec la prise en charge de l’API OpenAI Responses, de Google Gemini Interactions et d’OCI Generative AI, a ajouté un réglage Reasoning Effort pour les AI Agents et a introduit des identités managées pour les services OCI, afin que les identifiants n’aient pas à être stockés dans l’application. La refonte des Interactive Reports dans la même version a ajouté des puces de filtre, des filtres d’en-tête à sélection multiple et des colonnes calculées décrites en langage naturel. Si vous prévoyez d’intégrer des fonctionnalités d’IA dans des applications métier au-delà d’APEX, notre équipe couvre l’intégration de l’IA générative sur toutes les stacks.

Ce que 2026 n’a pas changé

Les versions 2026 n’ont pas modifié les fondamentaux d’APEX : c’est toujours une plateforme Oracle Database, toujours centrée sur les compétences SQL et PL/SQL, et toujours soumise à un rythme de publication rapide qui impose des mises à niveau régulières. Les organisations qui recherchent l’indépendance vis-à-vis de la base de données ou une stack orientée JavaScript ne les trouveront pas dans APEX 26.x.

Le rythme des mises à niveau mérite d’être planifié. Comme DSP le résume à propos de la politique de support d’Oracle, seules les deux dernières versions d’APEX sont prises en charge, chacune pendant environ 18 mois à compter de sa disponibilité générale ; selon ce calendrier, la 24.2 est prise en charge jusqu’à juillet 2027 environ et la 26.1 jusqu’à novembre 2027 environ. En pratique, une application APEX doit donc être mise à niveau à peu près une fois par an pour rester sur une version prise en charge.

Que peut-on construire avec Oracle APEX ?

Oracle APEX est idéal pour les applications métier centrées sur les données, lorsque ces données se trouvent déjà dans Oracle Database et que les utilisateurs doivent les rechercher, les modifier, les valider et en tirer des rapports. Sept cas d’usage couvrent la plupart des projets réels :

• Applications internes et de back-office : applications CRUD pour les commandes, les actifs, les contrats, les stocks ou la gestion de dossiers, construites sur des tables existantes.
• Applications de validation et de workflow : demandes d’achat, validations de changements et parcours d’intégration, avec validations intégrées, listes de tâches et notifications par e-mail.
• Tableaux de bord et reporting de type BI allégée : graphiques, KPI et rapports en libre-service sur les données opérationnelles, sans licence BI distincte pour chaque utilisateur.
• Extensions d’Oracle E-Business Suite et d’Oracle Fusion : écrans et processus que l’ERP ne couvre pas, construits à côté des données EBS ou sur les données Fusion via REST, sans personnaliser l’ERP lui-même.
• Remplacement d’Oracle Forms, d’Access et d’Excel : versions web modernes de modules Forms historiques et de processus pilotés par des tableurs, avec des données centralisées et des pistes d’audit.
• Portails clients et partenaires : portails libre-service sécurisés où les utilisateurs externes consultent leurs propres commandes, factures ou réclamations stockées dans Oracle.
• SaaS multi-tenant sur Oracle : produits SaaS métier dans lesquels les données de chaque client sont séparées dans la base et dont l’éditeur est déjà standardisé sur Oracle.

Que comprennent les services de développement Oracle APEX ?

Les services de développement Oracle APEX couvrent tout le cycle de vie d’une application APEX : la création de nouvelles applications, la modernisation de systèmes existants vers APEX, la mise à niveau et l’intégration de parcs APEX existants, ainsi que leur maintien en condition rapide, sûre et supportée. Un partenaire compétent devrait proposer l’essentiel de ce qui suit :

• Développement d’applications APEX sur mesure : nouvelles applications, des exigences et du modèle de données jusqu’à la production, authentification, rôles et reporting compris.
• Modernisation d’Oracle Forms et des systèmes existants : analyse des Forms, Reports, bases Access ou processus sur tableurs existants, puis reconstruction par phases sous forme d’applications APEX.
• Mises à niveau d’APEX : migration d’applications depuis d’anciennes versions comme la 19.x, la 21.x ou la 23.x vers la 24.2 et la 26.x, correction des composants obsolètes et adoption d’APEXlang.
• Intégrations : interfaces REST et ORDS avec les systèmes ERP, CRM, de paiement et SaaS, ainsi que l’authentification unique avec les fournisseurs d’identité de l’entreprise. Notre guide de l’intégration des systèmes d’entreprise détaille ces modèles.
• Travail UI et UX : mises en page, navigation et accessibilité sur l’Universal Theme et le thème Iris rafraîchi, avec des composants personnalisés uniquement lorsqu’ils sont rentables.
• Optimisation des performances : optimisation SQL et PL/SQL, stratégie d’indexation et de pagination pour les Interactive Reports et les Interactive Grid volumineux.
• Support et maintenance : supervision, correction de bugs, petites évolutions et cycle de mise à niveau planifié, aligné sur le calendrier de publication d’Oracle.

L’équilibre entre ces services dépend de votre point de départ. Un projet greenfield consacre l’essentiel de son budget à la phase de découverte et au développement, tandis qu’un parc existant dépense généralement davantage en mises à niveau, en performances et en refactorisation de pages accumulées au fil des années.

Comment se déroule le processus de développement APEX ?

Un projet APEX bien mené suit le même cycle de vie rigoureux que n’importe quel logiciel d’entreprise, avec simplement des itérations plus courtes, car des écrans fonctionnels peuvent être générés à partir du modèle de données en quelques heures. Les sept étapes ci-dessous forment une séquence pratique pour une nouvelle application ou une phase de modernisation.

1. Découverte et audit des données. Cartographiez les utilisateurs, les processus et le schéma existant, identifiez les problèmes de qualité des données et mettez-vous d’accord sur le périmètre. Livrable : un backlog priorisé, une ébauche du modèle de données cible et une estimation ferme pour la première version.
2. Modèle de données. Concevez ou refactorisez les tables, les vues et les packages PL/SQL avant de construire les écrans ; à partir de la 24.2, APEX peut proposer un modèle de départ grâce à la modélisation des données assistée par IA dans SQL Workshop. Livrable : un schéma relu, avec contraintes et données de test.
3. Prototype en quelques jours. Générez les pages principales à partir du modèle et présentez-les à de vrais utilisateurs dès la première ou la deuxième semaine, ce qui constitue une preuve de concept à faible risque, à la fois pour le processus et pour le choix de la plateforme. Livrable : un prototype cliquable sur des structures de données réelles.
4. Développement et intégration. Implémentez les règles métier dans des packages PL/SQL, connectez les sources REST et les systèmes cibles, et ajoutez l’authentification, les autorisations et l’audit. Livrable : des incréments fonctionnellement complets toutes les une à deux semaines.
5. Tests et revue de code. Relisez les diffs APEXlang dans les merge requests, exécutez des tests unitaires sur le PL/SQL (par exemple avec utPLSQL) et automatisez les parcours utilisateurs clés dans un outil de test navigateur. Livrable : un rapport de test et une suite de régression.
6. Déploiement via CI/CD. Faites passer les fichiers APEXlang et les scripts de base de données du développement vers le test puis la production au moyen d’un pipeline plutôt que par des exports manuels. Livrable : des mises en production reproductibles et auditables, avec scripts de retour arrière.
7. Mises à niveau et support. Planifiez une fenêtre de mise à niveau environ tous les 12 à 18 mois pour rester dans les versions prises en charge par Oracle, et suivez les performances et l’usage après la mise en service. Livrable : un calendrier de mises à niveau et un SLA de support.

Le principal gain de temps de ce processus ne vient pas du builder low-code lui-même, mais des retours utilisateurs précoces : comme les écrans APEX coûtent peu à modifier avant que la logique PL/SQL ne se fige, les problèmes de processus apparaissent dès la deuxième semaine plutôt qu’en recette utilisateur.

Comment migrer Oracle Forms vers Oracle APEX ?

On migre Oracle Forms vers Oracle APEX en traitant le projet comme une refonte : conservez et réutilisez la logique métier PL/SQL dans la base de données, mais reconstruisez les écrans et les parcours utilisateurs pour le web. Une conversion un pour un ne fonctionne pas, car Forms est un environnement avec état piloté par des triggers, alors qu’APEX est sans état et fondé sur des requêtes ; la FAQ d’Oracle sur la modernisation de Forms vers APEX fait d’ailleurs le même constat : aucun outil ne convertit Forms en APEX de manière entièrement automatique.

Le calendrier dépend des dates de support et de l’infrastructure. D’après les échéances publiées dans le cadre de la Lifetime Support Policy d’Oracle, telles que résumées par le guide de migration 2026 d’Aqlix, la dernière version d’Oracle Forms est la 14c (14.1.2), sortie en décembre 2024, avec un Premier Support jusqu’en 2030 et un Extended Support payant jusqu’en décembre 2033. Forms nécessite également WebLogic Server, contrairement à APEX ; abandonner Forms supprime donc généralement toute une couche middleware à licencier et à patcher. Le même guide estime, à titre d’estimation de prestataire, que les migrations de taille moyenne prennent environ 6 à 18 mois et les grands parcs 2 à 3 ans.

Oracle documente ce point de départ intégré dans son guide sur la création d’un projet de migration Forms vers APEX, qui analyse le XML des Forms chargé et aide à suivre l’état de chaque module.

Plan de migration de Forms vers APEX étape par étape

1. Inventaire et notation de la complexité. Listez chaque formulaire, rapport, bibliothèque et menu, relevez leur usage et notez chaque module selon ses triggers, ses blocs et ses intégrations afin de décider quoi migrer, fusionner ou retirer.
2. Analyse du XML des Forms. Convertissez les modules en XML et chargez-les dans un projet de migration APEX pour voir les blocs, les éléments et le code des triggers au même endroit.
3. Conception de l’UX cible. Concevez des parcours natifs du web (pages de recherche, maître-détail, assistants) plutôt que de copier les canevas Forms, et validez-les avec les utilisateurs clés.
4. Déplacement de la logique dans des packages de base de données. Extrayez les règles métier des triggers de formulaires vers des packages PL/SQL qu’APEX et tout autre client peuvent appeler.
5. Développement par phases et double exploitation. Reconstruisez les modules par ordre de priorité, faites-les tourner en parallèle de Forms si nécessaire et comparez les résultats sur des données réelles.
6. Formation et bascule. Formez les utilisateurs, basculez module par module, décommissionnez les Forms retirés et supprimez enfin WebLogic de la stack.

Pièges courants des projets Forms vers APEX

• Copie au pixel près. Recréer les canevas Forms dans un navigateur préserve des décennies de contournements et produit une application web plus lente et plus lourde.
• Logique des triggers laissée dans l’interface. Déplacer une logique de type WHEN-VALIDATE-ITEM dans des processus de page plutôt que dans des packages de base de données reproduit le problème de couplage d’origine.
• Oracle Reports oublié. Les rapports sont souvent plus nombreux que les formulaires et nécessitent leur propre plan, qu’il s’agisse du reporting APEX, de Data Reporter ou d’un outil distinct.
• Aucune base de référence pour les tests. Sans résultats attendus enregistrés à partir de l’ancien système, personne ne peut prouver que le nouveau calcule les mêmes totaux.

Les mêmes schémas se retrouvent dans les programmes de modernisation en général ; notre article sur les coûts de la modernisation legacy et les causes d’échec couvre l’analyse de rentabilité et les raisons les plus fréquentes pour lesquelles les projets s’enlisent.

Oracle APEX, autres plateformes low-code ou code sur mesure

Oracle APEX est l’option la plus solide lorsque les données résident dans Oracle et que l’application est centrée sur les données ; Microsoft Power Apps convient aux organisations Microsoft 365, OutSystems vise des portefeuilles d’applications d’entreprise plus larges, et le code sur mesure l’emporte lorsque l’UX, la montée en charge ou l’indépendance vis-à-vis de toute plateforme priment. La comparaison ci-dessous est qualitative et évite délibérément les chiffres de prix, car les licences des plateformes commerciales changent souvent et dépendent d’accords négociés.

Pour approfondir ce compromis, consultez notre comparaison entre no-code et développement sur mesure et notre grille de décision développer ou acheter un logiciel d’entreprise. Beaucoup d’organisations finissent avec un mélange : APEX pour les outils internes centrés sur Oracle et du code sur mesure pour les produits destinés aux clients.

Quand Oracle APEX n’est-il pas le bon choix ?

Oracle APEX n’est pas le bon choix lorsque les données ne résident pas dans Oracle, lorsque le produit s’adresse au grand public et repose sur le design, ou lorsque l’organisation prévoit de réduire sa dépendance à Oracle. Dans ces cas, l’avantage de vitesse du low-code est annulé par les contournements, la dépendance à l’éditeur et les contraintes de recrutement. Surveillez ces signaux :

• Données hors d’Oracle ou stratégie multi-bases. Si la plupart des données se trouvent dans PostgreSQL, SQL Server ou des entrepôts de données cloud, APEX ajoute une dépendance à Oracle au lieu de supprimer des frictions.
• Applications mobiles grand public, très axées design ou offline-first. Les expériences de marque au pixel près, les animations et les fonctionnalités natives de l’appareil coûtent cher à faire entrer dans un framework d’applications métier.
• Trafic public très élevé avec une interactivité front-end complexe. Les applications riches côté client destinées à de larges audiences anonymes sont mieux servies par une architecture front-end et API dédiée.
• Aucune compétence PL/SQL disponible. Si ni votre équipe ni votre marché du recrutement ne disposent d’une vraie expertise SQL et PL/SQL, la maintenance deviendra le goulot d’étranglement.
• Un plan stratégique pour quitter Oracle. Construire de nouvelles applications sur APEX renforce la dépendance que vous cherchez à réduire.
• Charges lourdes de temps réel et de streaming d’événements. Le traitement d’événements à haute fréquence et l’analytique en streaming conviennent mieux à des plateformes spécialisées qu’à un framework web fondé sur des requêtes.

Lorsque plusieurs de ces conditions s’appliquent, l’alternative est généralement une application sur mesure avec une couche API capable de continuer à lire les données d’Oracle pendant une transition. C’est le cœur du développement de logiciels d’entreprise : choisir l’architecture des dix prochaines années plutôt que le premier écran le plus rapide.

Combien coûte le développement Oracle APEX en 2026 ?

La licence de la plateforme Oracle APEX est généralement de 0 $ en plus d’une Oracle Database que vous possédez déjà ; les vrais coûts du développement de logiciels APEX sont l’effort d’ingénierie, l’hébergement et les mises à niveau régulières qu’impose le cycle de publication. Le tableau ci-dessous décompose le coût total de possession.

Les chiffres OCI proviennent de l’annonce d’Oracle selon laquelle l’éditeur a abaissé les barrières d’entrée grâce à une tarification par ECPU et par gigaoctet, qui a remplacé l’ancienne configuration d’entrée de gamme de 1 OCPU et 1 TB à 358 $ par mois, ainsi que de la page de tarification d’APEX. Les prix OCI évoluent : considérez-les comme une référence plutôt que comme un devis.

Au sein de l’effort d’ingénierie, ce sont ces facteurs qui font le plus varier l’estimation :

• Nombre et complexité des formulaires Oracle Forms et des rapports à migrer ou à remplacer.
• Intégrations avec les systèmes ERP, CRM, de paiement, de gestion documentaire et d’identité.
• Migration et nettoyage des données issues de tableurs, d’Access ou de schémas historiques.
• Authentification et SSO avec les fournisseurs d’identité de l’entreprise et des rôles fins.
• Exigences de conformité comme les pistes d’audit, la résidence des données et les revues d’accès.

À titre de référence issue de notre propre grille tarifaire de modernisation, les missions à périmètre fixe présentées sur notre page de modernisation logicielle commencent à 2 300 $ pour un audit de modernisation avec gains rapides, 9 200 $ pour une refactorisation systémique et 28 700 $ pour une modernisation complète, avec des devis en USD établis après une phase de découverte qui dure généralement 4 à 6 semaines. C’est au cours de cette phase de découverte, et pas avant, que l’on décide si la cible est APEX, du code sur mesure ou une combinaison des deux.

Comment choisir une société de développement Oracle APEX ?

Choisissez une société de développement Oracle APEX en vérifiant son expérience en production sur les versions actuelles, sa profondeur en bases de données au-delà de la simple construction de pages, et la crédibilité de son plan de tests, de sécurité et de mises à niveau. Une courte checklist permet de comparer les prestataires sur le fond plutôt que sur leurs présentations :

1. Des applications APEX 24.2 ou 26.x en production que le prestataire peut décrire en détail, y compris leur taille, leurs utilisateurs et leurs intégrations.
2. Une vraie expertise PL/SQL et performance des bases de données, pas seulement la construction de pages : demandez comment ils optimiseraient une Interactive Grid lente sur une table de plusieurs dizaines de millions de lignes.
3. Des références de migration Oracle Forms avec des délais honnêtes et des enseignements tirés, si la modernisation fait partie de votre périmètre.
4. Une pratique d’APEXlang, de git et de CI/CD : comment ils gèrent les branches, relisent et déploient les modifications APEX depuis les versions 26.1 et 26.2.
5. Un modèle de sécurité clair : schémas d’authentification, schémas d’autorisation, protection de l’état de session et utilisation de Deep Data Security dans la 26.2.
6. Un plan de mise à niveau et de support aligné sur la fenêtre de support d’Oracle, limitée à deux versions et d’environ 18 mois.
7. Une phase de découverte transparente à périmètre fixe avant toute estimation complète, avec des livrables que vous conservez même si vous changez de prestataire.

Oracle APEX est-il assez sûr pour les applications d’entreprise ?

Oui, Oracle APEX est suffisamment sûr pour les applications d’entreprise lorsque les équipes utilisent correctement le modèle de sécurité de la base de données et maintiennent les applications sur des versions prises en charge. Comme APEX s’exécute dans Oracle Database, l’accès aux données reste dans le périmètre de sécurité de la base au lieu de transiter par un serveur d’applications supplémentaire.

• Les schémas d’authentification s’intègrent aux fournisseurs d’identité de l’entreprise via des standards comme SAML et OpenID Connect, ainsi qu’à des schémas base de données et personnalisés.
• Les schémas d’autorisation contrôlent l’accès aux applications, pages, régions, boutons et processus en fonction des rôles.
• La protection de l’état de session empêche les utilisateurs de manipuler les paramètres d’URL et les valeurs des éléments de page.
• Deep Data Security dans APEX 26.2 vérifie les Data Roles et les Data Grants dans la base à chaque instruction SQL, y compris les appels REST et les actions des AI Agents, selon l’annonce d’Oracle pour la 26.2.
• Uniquement des versions prises en charge : rester sur les deux versions d’APEX actuellement prises en charge garantit la continuité des correctifs de sécurité.

Les fonctionnalités de la plateforme ne représentent que la moitié du travail ; le codage sécurisé, les revues et les tests comptent tout autant. Notre guide du cycle de vie du développement logiciel sécurisé explique comment intégrer ces contrôles à chaque version.

Questions fréquentes