@Work
La révolution « Opal » de Google envahit Gemini mais pas encore l’Europe
Par Laurent Delattre, publié le 19 décembre 2025
Le vibe coding déplace la création logicielle de la syntaxe vers l’intention. Avec Opal, Google pousse le no-code agentique dans son assistant Gemini, mais en interdit encore l’accès aux européens. Plus pour longtemps ?
Cet été, Google lançait un outil de Vibe-Coding dénommé Opal. Nous n’avions pas évoqué le sujet parce que l’outil n’était disponible qu’aux USA. En novembre, Google annonçait l’ouverture de l’accès à Opal dans 160 pays sauf ceux de la Communauté Européenne.
Soyons tout de suite clairs, Opal n’est toujours pas accessible depuis la France et les pays de l’UE. Mais l’annonce cette semaine de son intégration dans la Web App Gemini démontre que non seulement l’outil est désormais bien moins expérimental qu’au début mais aussi que Google commence à en accélérer l’ouverture et l’accès. Il y a donc fort à parier que l’éditeur ne tardera plus à en ouvrir l’accès aux européens.
Cette annonce d’une intégration dans Gemini est donc l’occasion pour nous de revenir sur un outil dont on entend de plus en plus souvent parlé et qui s’inscrit totalement dans la grande tendance 2025 du Vibe-Coding.
Vibe coding : un glissement du code vers l’intention
Le « vibe coding » s’est en effet imposé en 2025 comme le mot-valise qui résume une réalité déjà bien installée dans les équipes produit : on ne démarre plus forcément par l’architecture et les API, mais par une intention formulée en langage naturel, puis on laisse un système d’IA « faire le sale boulot » c’est-à-dire coder, générer, assembler, relier, itérer. Dans la définition la plus sobre, il s’agit d’une façon de développer où l’on décrit le résultat attendu et où l’IA se charge des détails, ce qui accélère surtout la production de prototypes et de petites applications.
Ce que le vibe coding raconte, côté entreprise, c’est d’abord l’évolution du rôle du développeur et, plus largement, de la chaîne de valeur logicielle. Le développeur n’est plus un « codeur » d’application mais un « créateur » d’applications. L’acte de coder se déplace vers l’acte de spécifier : clarifier un besoin, définir des contraintes, fournir des exemples, valider des comportements, écrire des tests, instrumenter et sécuriser. C’est un bon révélateur de la maturité atteinte par les « agents IA » et les assistants de développement : ils ne se contentent plus de proposer du code, ils orchestrent des séquences de tâches (comprendre le contexte, modifier des fichiers, exécuter des commandes, corriger, documenter), avec des niveaux d’autonomie croissants.
Mais le vibe coding n’est pas une méthode de production « sans discipline ». Dès qu’on sort du prototype, les invariants du développement d’entreprise reviennent au galop : traçabilité, qualité, dette technique, tests, revue, conformité, et surtout gouvernance de la donnée (ce que l’agent voit, ce qu’il envoie, ce qu’il mémorise). Autrement dit, le vibe coding est un accélérateur d’itération ; il n’abolit ni le SDLC, ni le DevSecOps, ni les exigences d’exploitation.
Opal : le no-code agentique de Google pour créer des mini-apps IA
C’est dans ce contexte que s’inscrit Google Opal. Annoncé le 24 juillet 2025 par Google Labs et enrichit depuis, Opal est un outil expérimental (en réalité de moins en moins expérimental et de plus en plus riche) permettant de « décrire, créer et partager » des mini-applications IA en combinant langage naturel et édition visuelle. L’idée est de chaîner prompts, modèles et outils, puis d’emballer le tout dans une petite expérience applicative partageable.
Opal n’a pas vocation à créer de grandes applications d’entreprises mais bien des mini-applications à usage relativement limité. Tout au moins pour l’instant.
Au cœur d’Opal, on retrouve une logique d’assemblage par étapes. La documentation Google décrit deux manières principales d’éditer un « Opal » : manipuler manuellement des étapes dans un éditeur visuel, ou demander des modifications en langage naturel via un éditeur dédié. La structure est volontairement explicite : des étapes de saisie utilisateur, de génération (avec sélection de modèle), et de sortie, avec la possibilité d’enchaîner les résultats d’une étape dans une autre, et d’exposer le tout sous forme de page dynamique ou même d’export (par exemple vers une feuille Google Drive).
Deux détails « d’implémentation » loin d’être anecdotiques ne manqueront pas d’interpeler les DSI. D’abord, Opal gère des ressources multimédias : on peut ajouter des « assets » (fichiers, images, lien YouTube) qui servent de contexte aux prompts. Ensuite, les Opals sont stockés comme des fichiers dans Google Drive. Ils en héritent donc des fonctionnalités de publication et partage à commencer par le contrôle des accès, la publication par lien, la gestion des droits et le suivi des versions antérieures. Une vraie mini gestion du cycle de vie des mini-apps, les Opals, réalisée via Google Drive. C’est malin.
Côté limites, Google positionne Opal comme une « experimentation » issue de ses Labs, et son lancement s’est fait en bêta publique, initialement limité aux États-Unis avant d’être progressivement étendue au monde entier (sauf à l’europe comme évoqué au début).
Plus structurellement, Opal est optimisé pour des mini-apps et des workflows IA réutilisables ; ce n’est pas un environnement d’ingénierie logicielle complet, ni un substitut à une plateforme de développement industrialisée (gestion fine des dépendances, outillage CI/CD, contraintes d’architecture, observabilité applicative, etc.). En pratique, Opal vise le « dernier kilomètre » du vibe coding : transformer une idée de workflow en expérience exécutable avec une UI, sans écrire de code.
Opal entre dans Gemini App via les « Gems »
L’actualité de la semaine, c’est l’intégration d’Opal dans la Gemini App, côté web afin de permettre aux utilisateurs de créer des mini-apps IA personnalisées, hébergées dans Gemini et que Google appelle des « Gems ».
Selon Google, Opal devient directement accessible dans Gemini web app « comme un moyen de créer des Gems expérimentaux », visible dans le gestionnaire de Gems, pour fabriquer des mini-apps réutilisables qui « personnalisent » davantage l’expérience Gemini.
Et l’éditeur en profite pour ajouter au passage une évolution ergonomique clé : un nouvel affichage transforme les prompts en liste d’étapes, ce qui rapproche Opal d’un concept mental de « workflow » et en présente un déroulement logique plus lisible, et donc plus éditable.
Pour aller plus loin, l’utilisateur peut basculer vers l’« Advanced Editor » proposé sur opal.google afin d’obtenir un contrôle plus granulaire.
Cette intégration est importante pour deux raisons. D’abord, elle consacre Opal comme future brique du Vibe Coding depuis Gemini et fait mécaniquement sortir l’application des Labs de Google et de son statut d’expérimentation.
Ensuite, elle repositionne les Gems sur l’échiquier : historiquement, ces derniers ressemblaient aux GPTs de ChatGPT (ou aux Artifacts de Claude AI) et pouvaient être perçus comme des versions personnalisées de Gemini créées pour des tâches spécifiques. Avec Opal, le Gem n’est plus seulement un « persona » conversationnel : il devient un mini-produit, une micro-application IA encapsulant un workflow, une interface et une réutilisabilité. Une prémisse d’agent IA en somme.
Dit autrement, les Gems deviennent des « AI mini-apps » dotées d’interfaces visuelles et de fonctions avancées, formées à partir de workflows empaquetés, éditables, partageables, et « propulsées par Opal ».
Pour un DSI, cela signifie qu’une partie des cas d’usage « automatisation légère » et « copilot métier » risque de se jouer directement dans l’écosystème Gemini, avec tous les sujets associés : contrôle des partages, gouvernance Drive, politiques d’accès, et capacité à éviter un nouveau Shadow IT, cette fois sous forme de micro-apps IA.
Sur le papier, Opal est la réponse de Google à Microsoft Copilot Studio qui permet de créer des agents en no-code puis de les publier via les différents canaux de l’écosystème Microsoft 365.
Parallèlement, son intégration dans Gemini est un nouveau signe d’une sorte de normalisation du vibe-coding et de son début d’implémentation au cœur de l’outillage de productivité et de création de workflows.
Autrement dit, les DSI vont désormais devoir non plus s’inquiéter de « qui code », mais également de « qui publie des workflows IA réutilisables, avec quelles données, quels partages, et quelle responsabilité opérationnelle ».
Un tel outil introduit en effet une forme de « Shadow Agentique » qui devrait se généraliser en 2026 et qui remet en premier plan la question de gouvernance de ces productions « IA no-code » réalisées par les collaborateurs hors IT. Il va falloir déterminer comment cadrer les cas d’usage, définir des règles de publication/partage, auditer les mini-apps, et décider où l’on tolère le prototype… et où l’on exige la filière d’industrialisation classique.
À LIRE AUSSI :
À LIRE AUSSI :
