Contexte et motivation
Mike Hichwa, vice‑président senior du génie logiciel chez Oracle, affirme que en 2025 la majorité du code était écrit par des humains, alors qu’en 2026 la majorité sera produite par des machines. Cette transition, qualifiée de « tipping point », impose aux entreprises de repenser la maintenance, la gouvernance et la lisibilité du logiciel produit automatiquement. Les plateformes low‑code, déjà conçues pour accélérer le développement, doivent donc intégrer des mécanismes de contrôle adaptés à la production massive de code par IA.
Architecture d’APEXlang et intégration IA
Oracle répond à ce besoin avec APEXlang, un langage de définition d’application hautement abstrait qui capture l’intention plutôt que l’implémentation concrète. La grammaire, les compétences et la documentation d’APEXlang sont publiées dans le domaine public, ce qui permet à des agents de génération comme Claude d’Anthropic ou Codex d’OpenAI de produire des artefacts compatibles. Oracle collabore également avec OpenAI pour entraîner des modèles capables de générer APEXlang de façon plus efficace, réduisant ainsi le nombre d’appels de génération nécessaires.
Le flux de travail typique consiste à fournir à l’IA une description fonctionnelle de l’application ; le modèle renvoie un fichier APEXlang qui est ensuite interprété par le moteur APEX. Ce moteur, mis à jour mensuellement par Oracle, assure la compatibilité ascendante et évite aux clients de devoir revisiter le code généré. L’interprétation en temps réel élimine la nécessité de compiler du code source volumineux, ce qui contraste avec les approches traditionnelles où chaque génération produit plusieurs centaines de lignes de code.
Gouvernance, maintenance et limites
La gouvernance repose sur deux leviers : la taille réduite du fichier APEXlang et le cycle de mise à jour du moteur. Hichwa souligne que « une définition compacte est plus lisible, donc moins sujette à l’« AI slop » », c’est‑à‑dire aux erreurs ou aux redondances introduites par les modèles génératifs. En pratique, un même artefact peut être généré 100 ou 1 000 fois au sein d’une organisation sans augmenter la charge de maintenance, car les modifications sont centralisées dans le moteur APEX et non dans chaque instance de code.
Cette approche présente toutefois des limites. La dépendance à un moteur propriétaire implique que les entreprises doivent accepter les mises à jour mensuelles d’Oracle, ce qui peut introduire des incompatibilités inattendues si les modèles IA ne sont pas synchronisés avec la version du moteur. De plus, la publication de la grammaire ne garantit pas que tous les modèles IA respectent les contraintes de sécurité ou de conformité, ce qui oblige les équipes à mettre en place des audits supplémentaires avant le déploiement en production.
