Le SaaS ne se mesure pas au nombre de lignes de code délivré
Dans une application sur mesure, l'équipe produit principalement du code. La spécification décrit le comportement attendu, les agents peuvent générer les composants, puis la chaîne CI/CD vérifie et déploie le résultat. C'est le principe de Niji ARC™.
Une solution SaaS est déjà construite et opérée par un éditeur. L'équipe projet l'adapte en combinant configuration, métadonnées, extensions, intégrations et, lorsque cela est nécessaire, code spécifique. La solution doit rester proche du standard pour bénéficier des mises à jour et éviter une dette spécifique excessive.
Le sujet n'est donc pas de transposer mécaniquement les pratiques de l'AI-native delivery. Il est de les adapter à une plateforme dont une partie du comportement est décrite de manière déclarative et parfois modifiée directement dans une interface d'administration.
SaaS et sur-mesure : deux modèles de delivery
Une application sur mesure permet de décider de presque tout, au prix d'un effort important de conception, de développement et de maintenance. Une solution SaaS apporte un standard riche, mais impose ses concepts, son modèle de sécurité, ses limites et sa roadmap.
| Dimension | Solution SaaS | Solution sur mesure |
|---|---|---|
| Point de départ | Un produit standard déjà opéré par un éditeur | Un socle technique à concevoir ou assembler |
| Personnalisation | Configuration, métadonnées, extensions et intégrations | Code applicatif, données, infrastructure et intégrations |
| Livraison | Un état de plateforme et ses métadonnées | Des composants logiciels et d'infrastructure |
| Risque principal | Dérive de configuration et dépendance à l'éditeur | Dette technique et coût de maintenance du code |
Les métadonnées, le langage des plateformes SaaS
Une métadonnée décrit la structure ou le comportement d'une application : objet métier, champ, écran, règle, workflow, permission ou composant d'interface. Elle ne contient pas nécessairement les données métier. Elle décrit la manière dont la plateforme doit les gérer.
Le code exprime des instructions. La métadonnée décrit plutôt un état cible ou une intention fonctionnelle que la plateforme interprète. C'est ce qui rend possible le low-code, mais aussi ce qui impose de rendre les changements explicites et contrôlables.
Le low-code apporte déjà un gain de productivité en réduisant la quantité de développement manuel. Une étude expérimentale publiée par l'ACM a observé, sur trois technologies et dans un environnement contrôlé, une productivité environ trois à dix fois supérieure à une approche code-based. Ce résultat dépend du périmètre, des outils et des compétences. Il ne constitue pas une promesse universelle, mais rappelle qu'une partie du travail peut être prise en charge directement par la plateforme.
L'IA a d'abord accéléré les solutions pro-code
Pourquoi les LLM sont efficaces pour générer du code
Les LLM sont particulièrement performants pour générer du code parce que celui-ci est un langage structuré, riche en régularités et représenté par de nombreux exemples. Les syntaxes, les bibliothèques, les conventions et les patterns d'architecture offrent au modèle un cadre relativement prévisible.
Cette capacité permet de générer des fonctions, des classes, des composants, des tests et de la documentation à partir d'une consigne. Elle ne signifie pas pour autant que le modèle comprend toujours l'intention métier ou que le code produit est correct. La plausibilité syntaxique ne garantit ni le bon comportement, ni la maintenabilité, ni la sécurité.
De la génération au contrôle
Dans une approche pro-code, l'agent peut accélérer plusieurs étapes du développement : création de fichiers, implémentation, refactoring, écriture de tests, analyse d'erreurs et documentation. Le risque se déplace alors de la production du code vers sa vérification.
Le delivery doit donc associer génération agentique et contrôles déterministes : compilation, linters, tests unitaires et d'intégration, analyse statique, détection des vulnérabilités, revue de code, couverture et CI/CD.
Le principe est simple : l'IA génère, le pipeline vérifie.
Quatre approches pour produire avec l'IA sur une solution SaaS
Ces approches peuvent se combiner, mais elles ne présentent ni le même niveau d'ouverture, ni la même robustesse, ni la même dépendance à l'éditeur.
L'éditeur ajoute un agent dans l'interface d'administration. L'utilisateur décrit son besoin, l'agent propose une modification et demande une confirmation. L'expérience est accessible et bénéficie du contexte de la plateforme, mais dépend fortement de la roadmap de l'éditeur.
Le Model Context Protocol permet à un éditeur d'exposer des ressources et des outils utilisables par un agent externe. Celui-ci peut alors lire une métadonnée, analyser un impact, lancer un test ou proposer un déploiement sans piloter l'interface graphique. Cette approche est adaptée à l'orchestration agentique, mais elle dépend de la qualité des outils fournis par l'éditeur.
La configuration est récupérée dans un format de projet, stockée dans Git, relue dans une pull request, testée dans un environnement dédié puis déployée par une chaîne CI/CD. C'est l'approche la plus proche des standards de l'industrie logicielle et la plus favorable à la traçabilité. Elle nécessite toutefois que la plateforme expose suffisamment ses métadonnées, ses dépendances et ses mécanismes de déploiement.
L'agent utilise l'interface comme un utilisateur humain. Cette technique peut dépanner lorsque la plateforme n'expose ni API, ni métadonnées exploitables, ni serveur MCP. Elle reste fragile, dépendante de l'interface et difficile à auditer. Elle doit être réservée aux prototypes ou aux tâches ponctuelles.
| Approche | Robustesse | Usage recommandé |
|---|---|---|
| Assistant de configuration intégré | Moyenne à forte | Administration et cas d'usage guidés |
| MCP | Forte si les outils sont gouvernés | Orchestration agentique |
| Métadonnées dans Git | Très forte | Industrialisation, audit et CI/CD |
| Navigateur | Faible | Dernier recours |
Le harnais d'IA est aussi indispensable pour les solutions SaaS
Une solution SaaS peut être configurée par un agent sans que le delivery soit maîtrisé. Pour passer à l'échelle, il faut une spécification, un contexte documenté, une comparaison avant-après, des tests automatisés et une validation humaine sur les changements sensibles. La chaîne CI/CD doit intégrer des linters, des quality checks, l'analyse des dépendances, les contrôles de sécurité et un déploiement réversible.
Le pipeline devient le point de contrôle entre la production de l'IA et la mise en production. Il vérifie que la configuration respecte les conventions, que les tests passent et que le changement peut être promu sans dégrader la solution. L'objectif n'est pas de supprimer les administrateurs, les développeurs ou les architectes, mais de réduire les manipulations répétitives et de concentrer l'expertise humaine sur la conception, la revue et les arbitrages.
Salesforce, un cas particulièrement favorable
Salesforce dispose d'un avantage historique : une grande partie de sa personnalisation est déjà formalisée sous forme de métadonnées. Objets, champs, flows, layouts, permissions et composants peuvent être récupérés, structurés et déployés avec l'outillage Salesforce DX.
L'écosystème réunit désormais plusieurs briques utiles au delivery agentique :
- Setup with Agentforce, pour assister les tâches d'administration dans l'org, avec confirmation avant modification ;
- Agentforce Vibes IDE, environnement de développement agentique disponible dans VS Code et sous forme d'IDE hébergé ;
- Salesforce DX MCP Server, pour fournir aux agents des outils structurés de synchronisation, de test et de déploiement ;
- Salesforce DX Source Format, pour gérer les métadonnées dans un projet et un système de contrôle de version ;
- Code Analyzer et ApexGuru, pour renforcer les contrôles de qualité, de sécurité et de performance.
Pour nos clients, l'enjeu est désormais de les relier dans une méthode de delivery réellement industrialisée.
Conclusion : les solutions SaaS doivent devenir « AI-operable »
L'IA réduit le coût de production d'une solution spécifique. Avec elle, l'arbitrage entre Make et Buy redevient central. La valeur d'une plateforme SaaS ne dépendra donc plus seulement du nombre de fonctionnalités proposées, mais aussi de sa capacité à être comprise et manipulée par des humains et des agents, sans perdre la traçabilité ni la maîtrise des risques.
Les éditeurs devront documenter leur modèle de configuration, exposer des APIs, des CLI ou des serveurs MCP, rendre les métadonnées versionnables et comparables, et faciliter les tests, les promotions, les contrôles et le rollback.
Les solutions SaaS peuvent ainsi bénéficier des méthodes de delivery pilotées par l'IA, à condition de les adapter à leur réalité. Salesforce fait partie des plateformes les mieux positionnées pour cette évolution : son modèle de métadonnées, son outillage DX, ses capacités MCP et ses contrôles de qualité fournissent déjà plusieurs briques importantes.
À retenir. La configuration et les métadonnées deviennent des actifs logiciels à part entière. La réussite ne viendra pas d'une simple interface conversationnelle, mais d'une chaîne cohérente entre spécification, génération, vérification et déploiement.
