DEV Community: Nicolas GUILHEM

Conférence Dev With AI 2026 : une première édition prometteuse malgré les imprévus

Nicolas GUILHEM — Thu, 15 Oct 2026 07:52:15 +0000

Retour d'expérience co-écrit par Ivan Bethus, Thomas Petit et Nicolas Guilhem.

Intelligence artificielle, mais pannes bien réelles

Nous partons de Bordeaux à l'aube pour assister à la première édition de Dev With AI, attirés par une journée autour de l'IA, des retours d'expérience et des échanges entre développeurs. Malheureusement, notre train a près de deux heures de retard : nous arrivons à Paris vers 10h30, juste au moment de la première pause, après avoir manqué les deux premières conférences.

Alors que nous nous réjouissons de pouvoir suivre notre premier talk, nous avons à peine le temps de prendre un café lorsque l'électricité saute, et pas seulement dans le centre de conférences : dans tout le quartier ! Nous évacuons, déçus...

Finalement, à 14h, le courant revient et la conférence peut reprendre. Les organisateurs suppriment les questions-réponses pour tenter de rattraper le retard, ce qui sera presque le cas ; nous manquerons tout de même les derniers talks, qui auront lieu après 18h.

Heureusement, certaines présentations ont retenu toute notre attention !

La Conversation Review : le guide pour faire progresser les équipes AI-native - Marek Kalnik

Dans sa conférence, Marek Kalnik propose de repenser l'exercice de la code review à l'ère de l'IA. Son idée consiste à introduire une revue des conversations ayant conduit à la génération du code, au même titre que les revues de code que nous pratiquons déjà.
Puisque nous sommes maintenant presque tous des Vibecoders (AI native, je n'ai toujours pas compris ce que ce terme voulait dire) et que nous ne produisons plus le code, pourquoi s'attacher à le relire ? Marek nous invite à relire ce qui a servi à le générer, c'est-à-dire notre propre production : la conversation que nous avons eue avec l'agent de code. Elle consiste à vérifier avec le développeur ses prompts, les différents messages échangés, les outils utilisés par le LLM, etc., afin d'identifier les points d'amélioration et de partager les bonnes pratiques avec le reste de l'équipe.
Cette pratique semble particulièrement adaptée pour faire grandir une équipe de dev, en l'accompagnant de l'adoption des pratiques agentiques à l'industrialisation et à la mutualisation des compétences associées.

La guerre des tokens - Philippe Prados

Philippe Prados prend le temps de disséquer ce qu'il y a vraiment dans un prompt d'agent : le System, les Tools, les AGENTS.md, les Rules, les Skills, le Style, la Memory, l'historique. Et une fois que le tableau est posé, on entre dans le détail de la façon d'optimiser sa consommation de tokens.

Côté outils, l'idée est de ne plus tout charger d'un coup. Les descriptions d'outils (desc + schema) et les listings MCP saturent vite. Le principe : passer par un Tool search plutôt que de tout charger, et utiliser un MCP d'indexation (/ide, ast-grep, LSP) pour que l'agent trouve directement le fichier, ou son contenu, au lieu de tout lire.

Pour les AGENTS.md, du bon sens : les préférences perso restent au niveau utilisateur, et le projet ne contient que ce qui lui est spécifique. Rien de générique qui viendrait alourdir inutilement. Le /doctor de Claude est là pour auditer tout ça.
Sur le choix du modèle, là aussi, du classique : Opus pour planifier, Sonnet pour coder, Haiku pour le répétitif. Et /model opusplan quand on hésite : il planifie avec Opus puis bascule en Sonnet pour l'exécution.

J'ai beaucoup aimé Caveman. C'est un style condensé qui compresse aussi, au passage, les AGENTS.md et les Skills, sans toucher au thinking.

La mémoire, oui, ça coûte, mais à l'échelle d'une équipe, ça s'amortit. Au prix de quelques tokens, elle améliore la recherche et la pertinence. Parmi les outils cités, je retiens : /memory, /dream, Memsearch, mempalace, Serena, Hindsight, Entire.

On termine sur les sorties de terminal, le piège silencieux par excellence. Un cat verbeux et c'est tout l'historique qui gonfle. D'où RTK, Snip, Token-saver et curl.md/<url> (https://curl.md/).

Beaucoup d'éléments de ce talk sont séduisants, et cela donne envie d'auditer sérieusement sa propre consommation.
Ce talk est très instructif, et une formule résume bien le tout :

le glissement du how to do vers le how to think

On ne cherche plus à exécuter, mais à faire penser l'agent plus efficacement.

Coder plus vite avec l'IA - Florian Bruniaux

Florian Bruniaux (contributeur de RTK) nous a proposé de nous intéresser au nouveau goulot d'étranglement du développement : la code review.
Si les IA produisent du code en grande quantité et rapidement, la review, elle, prend toujours un temps colossal aux équipes de dev. Alors comment tenter de résoudre ce problème ?

Quelques pistes, tirées de ses propres projets :

Pull requests

Faire générer par l'IA des PRs claires et correctement détaillées, pensées pour des relecteurs humains.
Ajouter un label sur les PRs pour savoir si une relecture humaine est nécessaire ou non (purement technique vs métier / sensible).

Review automatique

CodeRabbit -> efficace mais assez cher
friendlyReviewer -> Encore jeune, mais moins onéreux et de qualité
Bot custom -> plutôt orienté métier

Une fois les reviews effectuées, un skill fusionne les feedbacks des différents outils et les valide ou non, ce qui permet de savoir s'il faut reprendre la PR.

Enfin, Florian nous a exposé sa vision de l'investissement du temps de travail des développeurs de demain :

Dans le system design et la planification
Dans le retravail à la suite de la code review

En somme, très peu de temps passé sur la production de code elle-même. C'est un point qui a d'ailleurs été remonté par quasiment tous les intervenants.

Verdict

Nous avons dû quitter la salle avant la fin pour attraper notre train, et nous avons raté les derniers talks, dont celui de Katia Gil Guzman d'OpenAI, que nous attendions pourtant avec impatience. Cette journée nous laisse de bonnes idées, des pistes à explorer sur nos pratiques de développement avec l'IA et un beau moment partagé entre collègues. Pour les prochaines éditions, nous espérons un peu moins de redondance entre les sujets et peut-être davantage d'espaces pour échanger entre les talks (et oui, nous étions tout de même près de quatre cents personnes).

C'était une première édition, et elle ne peut que se bonifier !

Langfuse : combler l'angle mort de l'observabilité des agents IA

Nicolas GUILHEM — Mon, 14 Sep 2026 08:27:04 +0000

Le constat : Grafana, Datadog et consorts ne suffisent plus

Depuis quelques années, nous avons industrialisé le suivi de nos applications avec des outils d'observabilité éprouvés : Grafana, Datadog, Dynatrace, Splunk, ... Ces plateformes excellent pour surveiller l'infrastructure, la disponibilité des services, les temps de réponse HTTP ou la consommation des ressources. Elles restent indispensables, y compris pour les briques qui exposent des fonctionnalités agentiques.

Le problème, c'est qu'un agent IA ne se résume pas à un service qui répond vite ou lentement. Un agent peut répondre en 800 ms, ne lever aucune erreur applicative, consommer un budget de tokens raisonnable, ... et pourtant halluciner, choisir le mauvais outil, boucler sur une étape, ou tout simplement produire une réponse qui ne satisfait pas l'utilisateur. Ces dysfonctionnements sont invisibles pour un outil d'APM (Application Performance Monitoring) classique, car ils ne se traduisent ni par une erreur HTTP, ni par un pic de latence, ni par une alerte système. Ils se nichent dans le raisonnement de l'agent, dans l'enchaînement de ses appels d'outils, dans la qualité sémantique de sa sortie.

Sans outillage dédié, la maintenance de ces fonctionnalités agentiques devient vite un cauchemar : impossible de savoir pourquoi un agent a mal répondu à un utilisateur particulier, impossible de mesurer objectivement si une évolution de prompt améliore ou dégrade la qualité perçue, impossible de rejouer un cas problématique pour le corriger durablement. C'est exactement le vide que des plateformes comme Langfuse viennent combler, en se positionnant en complément (et non en remplacement) des outils d'observabilité traditionnels.

C'est d'ailleurs précisément ce qui distingue un POC d'une application agentique qui tient réellement la distance en production : ce n'est pas la sophistication de l'agent au moment de sa démonstration, mais la capacité de l'équipe à observer, comprendre et corriger ses dérives une fois confronté aux usages réels. Un agent non observé sur ces aspects fonctionnels reste fragile par construction, quelle que soit la qualité initiale de son prompt ou du modèle choisi.

Langfuse : une plateforme pensée pour l'amélioration continue

Langfuse est une plateforme open source d'ingénierie LLM qui couvre le tracing, l'évaluation, la gestion des prompts et l'expérimentation. Contrairement à un outil d'APM généraliste, Langfuse part du principe qu'une application agentique n'est jamais "finie" : elle s'améliore par itérations successives, guidées par des signaux de qualité réels : feedback utilisateur, scores d'évaluation, comparaison de versions de prompts. C'est cette boucle d'amélioration continue de la satisfaction utilisateur qui structure l'ensemble de la plateforme, et qui se retrouve dans trois fonctionnalités clés.

1. Découpler la gestion des prompts de l'application

Dans la plupart des applications LLM, les prompts sont codés en dur et versionnés avec le reste du code applicatif. Résultat : le moindre ajustement de formulation nécessite une revue de code et un cycle de déploiement complet, alors qu'il s'agit parfois d'une modification uniquement de reformulation ou complétude du prompt.

La gestion des prompts de Langfuse répond directement à ce problème en centralisant les prompts dans la plateforme plutôt que dans le code :

Versionning natif : chaque modification crée une nouvelle version, avec un système de labels (production, staging, latest...) pour piloter les déploiements par environnement et revenir instantanément à une version antérieure en cas de régression.
Mise à jour sans redéploiement : les équipes produit ou les experts métier peuvent ajuster un prompt directement dans l'interface, l'application allant chercher la nouvelle version automatiquement, sans redéploiement ni implication de l'équipe technique.
Lien avec les traces : chaque génération peut être rattachée à la version du prompt qui l'a produite, ce qui permet ensuite de comparer objectivement les métriques (qualité, coût, latence) entre deux versions d'un même prompt.
Intégration via SDK officiels : les SDK natifs Python et JS/TS récupèrent les prompts avec mise en cache côté client, sans ajouter de latence perceptible à l'application (cf. documentation). Pour les stacks Java/Spring, le client Java officiel langfuse-java, expose les mêmes ressources (prompts, scores, datasets...) sous forme d'un client généré à partir de la spécification de l'API.
Intégration via API : lorsqu'aucun SDK officiel ne couvre le langage ou le cas d'usage visé, l'ensemble des fonctionnalités reste accessible en HTTP pur via l'API Langfuse, qui documente le contrat OpenAPI complet (endpoints, paramètres, schémas de réponse) et permet de construire son propre client dans n'importe quel langage.

Ce découplage change fondamentalement la dynamique d'itération : le prompt engineering devient un cycle continu et mesuré, plutôt qu'un sous-produit du cycle de développement classique. Il peut être confié en toute sécurité a des populations non tech.

2. Suivre le "scoring" en temps réel

La deuxième pierre angulaire de Langfuse, ce sont les scores, l'objet universel de la plateforme pour stocker tout jugement de qualité sur une sortie d'agent, qu'il vienne d'un humain, d'un utilisateur final, d'une vérification programmatique ou d'un LLM as Judge.

Trois grandes sources alimentent ce scoring :

Le feedback utilisateur explicite ou implicite : un pouce levé/baissé, une note, ou même un signal indirect (ticket résolu ou escaladé) peut être remonté depuis l'application et attaché directement à la trace correspondante.
Les évaluateurs "LLM-as-a-judge" : Langfuse permet de configurer des évaluateurs automatisés qui utilisent un modèle pour juger une sortie selon une grille de critères personnalisée (pertinence, ton, absence d'hallucination...), avec un score et une justification, appliqués en continu sur le trafic de production. Nécessite une connexion à un LLM (en direct ou via une gateway) avec une attention particulière à porter sur la consommation notamment pour les évaluations si les datasets utilisés sont volumineux (cf. § Dataset et expérimentations ci-dessous)
Les évaluateurs par code : pour les vérifications déterministes (format, présence de données personnelles, règles métier), Langfuse permet également de brancher des évaluateurs programmatiques (Python ou TypeScript uniquement), déclenchés automatiquement selon des règles sur les observations entrantes.

L'ensemble de ces scores alimente des tableaux de bord et des alertes, ce qui transforme un flux de traces brutes en un signal de pilotage exploitable au quotidien par les équipes produit et technique.

3. Évaluer et expérimenter les évolutions avant de les déployer

Le troisième pilier permet de sortir du "ça a l'air de mieux marcher" pour objectiver l'impact d'une évolution (nouveau prompt, changement de modèle, nouvelle logique d'orchestration) avant sa mise en production.

Cela repose sur les Datasets et Experiments de Langfuse :

Un Dataset est une collection d'entrées, avec ou sans sortie attendue, qui sert de jeu de test pour l'application.
Ces jeux de données peuvent être importés (CSV, JSON) mais aussi et surtout complétés directement à partir des traces de production : un cas réel problématique remonté par un utilisateur peut être transformé en cas de test permanent, garantissant qu'il ne se reproduira pas silencieusement.
Une expérimentation fait ensuite tourner ce dataset à travers l'application (ou un prompt donné) et applique les méthodes d'évaluation vues plus haut (LLM-as-a-judge, code, revue manuelle) pour comparer objectivement les versions entre elles, via SDK, via l'interface, ou via OpenTelemetry.

Cette boucle "production → dataset → expérimentation → déploiement" est ce qui permet de faire évoluer un agent avec confiance, plutôt qu'à l'aveugle.

Les autres atouts qui font la différence

Au-delà de ces trois piliers, quelques caractéristiques structurantes justifient l'adoption de Langfuse à l'échelle d'une organisation :

Open source, déployable on-premise ou en SaaS : Langfuse est publié sous licence MIT et peut être auto-hébergé via Docker ou Kubernetes, sur la même base de code que l'offre Saas. Cela permet de garder les données sensibles (prompts, traces, contenus utilisateurs) dans son propre périmètre, y compris dans des environnements sans accès internet, tout en gardant la possibilité de basculer vers l'offre SaaS si besoin.
Une intégration large avec l'écosystème : Langfuse s'appuie sur OpenTelemetry et propose des intégrations natives avec la plupart des frameworks agentiques (LangChain/LangGraph, LlamaIndex, CrewAI, Spring AI, Quarkus LangChain4j, Koog, Embabel, ...) ainsi qu'avec les principales gateways LLM comme LiteLLM ou OpenRouter, ce qui limite fortement le travail d'instrumentation.
La visualisation du graphe agentique : au-delà de la vue classique en arborescence, Langfuse peut représenter graphiquement le flux d'un agent (délégation entre sous-agents, séquence d'outils appelés), un rendu particulièrement utile pour déboguer des orchestrations multi-agents complexes.

Se faire une idée par soi-même, à moindre coût

Avant de généraliser l'usage de Langfuse à une organisation entière, rien ne remplace un premier contact concret avec l'outil. D'autant que les différentes façons d'y accéder permettent de commencer sans un gros investissement initial :

Projet exemple : Lagfuse met à disposition un projet exemple servant de démonstration. La plateforme est préchargé avec des traces, des prompts et des évaluations réelles, à explorer librement avant de se lancer sur son propre cas d'usage.
Langfuse Cloud (SaaS) : la voie la plus rapide pour se faire un avis, via un compte géré par l'éditeur, avec un palier gratuit généreux et sans carte bancaire. La contrainte à garder en tête est que les données (prompts, traces, contenus échangés) transitent alors par l'infrastructure de Langfuse, ce qui peut être un point d'attention selon la sensibilité des données manipulées.
Sur sa machine locale (Docker Compose) : la solution la plus simple pour un test rapide en environnement de développement en quelques minutes pour lancer docker compose up (cf. documentation officielle). C'est idéal pour explorer les fonctionnalités ou prototyper une intégration.
Self-hosted en production : la même base de code que le SaaS, déployable via Docker, Kubernetes/Helm ou sur les principaux cloud providers. La contrainte est ici opérationnelle : il faut exploiter soi-même les composants de stockage (Postgres, ClickHouse, Redis, object storage), ce qui demande un minimum de maturité DevOps, en échange d'une maîtrise complète de la localisation des données.

Dans les trois cas, le coût d'entrée reste donc marginal comparé à l'effort de mise en place d'un outillage maison équivalent, ce qui permet de valider la pertinence de l'outil sur un cas d'usage réel avant d'investir dans un déploiement plus structurant.

Conclusion

Langfuse ne remplace pas Grafana, Datadog ou Dynatrace : il vient combler ce que ces outils ne sont pas conçus pour voir. C'est à dire la qualité fonctionnelle et perçue d'un agent IA. Le versionning des prompts découplé du code, le scoring en temps réel des interactions, et l'évaluation systématique des évolutions via des datasets alimentés par la production forment une boucle cohérente et rapide à mettre en place : quelques dépendances Maven ou quelques lignes de configuration OpenTelemetry suffisent généralement pour obtenir les premières traces exploitables.

C'est précisément cette simplicité de prise en main qui en fait un outil difficile à contourner sur le long terme : dès qu'une fonctionnalité agentique quitte le stade du prototype pour être maintenue dans la durée, l'absence d'un outil de ce type transforme chaque évolution de prompt ou chaque signalement utilisateur en enquête manuelle et non reproductible. À l'inverse, une équipe outillée avec Langfuse dispose d'une mémoire objective de la qualité de son agent, et peut faire de son amélioration continue un processus mesuré plutôt qu'un pari.

Sources : documentation officielle langfuse.com/docs

Les Cloud Development Environments (CDE) - Embarquement immédiat !

Nicolas GUILHEM — Thu, 06 Nov 2025 14:56:42 +0000

Dans le monde du développement logiciel, l'onboarding des nouveaux développeurs peut être un véritable casse-tête. Installation des outils, configuration de l'environnement, résolution des incompatibilités... Autant de problèmes que les Cloud Development Environments (CDE) promettent de résoudre. Mais avant de plonger dans le monde des CDE, il est essentiel de comprendre les technologies qui les sous-tendent : les DevContainers et les DevFiles.

DevContainers et DevFiles

Qu'est-ce qu'un DevContainer ?

Un DevContainer est une spécification qui formalise la description d'un environnement de développement conteneurisé. Initiée par Microsoft en 2022, cette spécification est aujourd'hui adoptée par de nombreux IDE comme VS Code, IntelliJ et bien d'autres. Mais bien avant le financement massif par Microsoft (via Github, VSCode, ...), c'est Red Hat qui en était le précurseur dans le domaine avec ses DevFile via le projet Eclipse Che (adopté par la CNCF en 2022).

La philosophie est simple : développer dans un conteneur avec tous les outils nécessaires pré-installés et configurés. Cela permet de :

Standardiser les environnements de développement entre tous les développeurs
Garantir la reproductibilité de l'environnement
Simplifier l'onboarding des nouvelles recrues

Pour en savoir plus, consultez les ressources officielles :

Site officiel : https://containers.dev/
Spécification : https://github.com/devcontainers/spec

DevContainers vs Docker Compose : Quelle différence ?

On pourrait croire qu'un DevContainer n'est qu'un simple Docker Compose déguisé. En réalité, il s'agit d'une couche d'abstraction au-dessus de Docker (ou d'autres runtimes comme Podman) qui simplifie considérablement la construction et l'exécution du conteneur.

Les DevContainers apportent des fonctionnalités spécifiques au développement :

Injection automatique de la configuration Git et SSH
Installation de fonctionnalités supplémentaires via les "features"
Montage automatique des volumes sources
Gestion du cycle de vie (build, create, start, stop)

Mise en oeuvre

Pour mettre en place un DevContainer, il suffit de créer un répertoire .devcontainer contenant un fichier devcontainer.json qui respecte la spécification. Voici la configuration minimale :

{
    "name": "Spacesuits dev container",
    "image": "mcr.microsoft.com/devcontainers/java:1-21-bullseye"
}

Cette simple configuration suffit à démarrer ! Microsoft propose déjà plus d'une centaine d'images de base prêtes à l'emploi (cf. templates pre-build).

Les features : personnalisez votre environnement

Les features sont des scripts shell exécutés lors de la construction de l'image. Ils permettent d'installer des outils supplémentaires de manière déclarative :

{
    "name": "Spacesuits dev container",
    "image": "mcr.microsoft.com/devcontainers/java:1-21-bullseye",
    "features": {
        "ghcr.io/devcontainers-extra/features/maven-sdkman:2": {
            "version": "3.9.11"
        }
    }
}

Plus d'un millier de features sont disponibles, et vous pouvez même créer les vôtres (privé ou partagé) !

Configuration avancée

Les DevContainers permettent une configuration très fine de l'environnement. Notamment par des hooks pour l'exécution de commandes aux différentes étapes de la construction de l'environnement.

{
    "name": "Spacesuits dev container",
    "image": "mcr.microsoft.com/devcontainers/java:1-21-bullseye",
    "features": {
        "ghcr.io/devcontainers-extra/features/maven-sdkman:2": {
            "version": "3.9.11"
        }
    },
    "postCreateCommand": "cd backend/space-suit-back && mvn compile",
    "forwardPorts": [ 8080 ]
}

Cette configuration permet de :

Exécuter des commandes après la création du conteneur
Forwarder automatiquement les ports
Définir des points de montage personnalisés
Configurer des variables d'environnement

Personnalisation de l'IDE

Les DevContainers permettent également de personnaliser l'IDE lui-même (structure spécifique à chaque outil implémentant la spécification : https://containers.dev/supporting) :

{
    "customizations": {
        "vscode": {
            "settings": {
                "editor.tabSize": 2
            },
            "extensions": [
                "redhat.vscode-quarkus"
            ]
        }
    }
}

Ainsi, tous les développeurs partagent non seulement le même environnement technique, mais aussi la même configuration d'IDE !

Cloud Development Environments

Histoire des CDE

Les environnements de développement dans le cloud ne datent pas d'hier :

Les Précurseurs (2010-2014)

Cloud9 (2010) : Premier IDE cloud majeur, révolutionnaire pour l'époque mais sans conteneurisation
Codeanywhere (2013) : IDE collaboratif dans le navigateur

Le Game Changer

En 2014, Codenvy, en se basant sur la spécification introduite par le projet open source
Eclipse Che, créé le premier IDE 100% orienté cloud. L'idée : pouvoir réaliser le dévelopement et la création d'un livrable uniquement sur des plateformes cloud.
C'est à cette période que le concept des DevFiles a été incubé. En 2019, Eclipse Che supporte officiellement les DevFiles et Codenvy est racheté par RedHat.

La Popularisation (2019-2022)

RedHat OpenShift Dev Spaces (2019 - DevFiles)
Microsoft GitHub Codespaces (2020 - DevContainers) : Adoption massive grâce à l'intégration avec GitHub et VScode
Google Cloud Workstations (2022 - DevContainers)

Comment fonctionnent les CDE ?

Il existe deux modes de fonctionnement principaux pour les CDE :

1. À la Main

Avec des outils comme DevPod ou Daytona, le développeur lance lui-même son CDE. Ces solutions :

Permettent de choisir le provider (environnement local, cloud, Kubernetes, etc.)
Configurent automatiquement la connexion SSH
Démarrent un serveur SSH chez le provider pour router les services
Le backend de l'IDE tourne sur le provider, le frontend en local

DevPod est particulièrement intéressant car il fonctionne sans paywall et supporte de nombreux providers.

Diagramme de composant de DevPod

2. À Distance

Des solutions comme Coder, Gitpod (récemment renommé Ona, Theia Cloud ou Lapdev proposent une approche différente où tout est géré à travers une interface web.

Coder mérite une attention particulière car il peut être totalement self-hosted. Son architecture repose sur :

Un service coderd qui gère la création des workspaces et la connexion des machines
Des workspaces avec durées de vie limitées (configurables par l'admin)
Une sauvegarde des modifications même si le workspace est arrêté

Diagramme d'infrastructure simplifié de Coder

CDE : Avantages et inconvénients

Les inconvénients

Soyons honnêtes sur les contraintes !

📡 Accès au réseau : Nécessite une connexion internet stable (les machines savent se reconnecter en cas de coupure)
🎛️ Complexité initiale : Le setup initial peut être complexe selon les solutions
💰 Coût ou infrastructure dédiée : Solutions SaaS coûteuses ou nécessité d'une infrastructure self-hosted
👶 Technologie récente : Encore des progrès à faire sur l'intégration

Les avantages

En revanche, es bénéfices sont nombreux :

⚡ Onboarding instantané : Les nouveaux développeurs peuvent travailler dès le jour 0
🔄 Environnement reproductible : Mêmes versions et configurations partout
🔒 Isolement : Le code source est isolé sur un serveur (même s'il transite forcément sur le réseau)
🛠️ Configuration centralisée : Gérée par l'équipe DevOps
💻 Machines légères : Plus besoin de machines de guerre pour les développeurs

Pour quel public ?

Les CDE sont particulièrement adaptés pour :

Grandes équipes : Standardisation à grande échelle
Turnover important : Onboarding simplifié
Configuration complexe : Environnements difficiles à reproduire localement
Sécurité cruciale : Code sensible qui ne doit pas quitter l'infrastructure
Formation technique : Environnement éphémère préinstallé
Projets open-source : Permet aux contributeurs de démarrer rapidement

Conclusion

Les Cloud Development Environments représentent une évolution majeure dans la façon dont nous développons des logiciels. En s'appuyant sur les DevContainers et les DevFiles, ils offrent une solution élégante aux problèmes d'onboarding et de standardisation des environnements.

Que vous choisissiez une solution "à la main" comme DevPod pour garder le contrôle, ou une solution managée comme Coder ou GitHub Codespaces pour déléguer la gestion de l'infrastructure, les CDE promettent de transformer radicalement l'expérience de développement.

La technologie est encore jeune, mais son adoption croissante par les géants du cloud et les entreprises innovantes montre que nous ne faisons qu'entrevoir le potentiel des environnements de développement dans le cloud.

Il est fort probable que de nouvelles plateformes de développement voient le jour dans les prochains mois incluant nativement des solutions agentiques (à l'image de l'IDE Kiro d'AWS mais transposé dans le cloud) 📻.

Pour aller plus loin

🎬 Développe sur un toaster grâce à Coder
📄 Documentation Coder Infrastructure
📄 Introduction à Eclipse Che
📄 Awesome DevContainers - Liste de templates
🌐 Spécification DevContainers