Il y a quelque chose d’étrange dans la manière dont on construit des pipelines CI/CD en 2026.
On parle d’infrastructure as code. De cloud natif. De microservices. De containers. Et pourtant, quand il s’agit de CI/CD, on continue à écrire des YAML gigantesques remplis d’étapes fragiles, dépendantes de runners capricieux et d’environnements difficiles à reproduire.
Chaque équipe a son fichier .gitlab-ci.yml, son workflow GitHub Actions, ses hacks maison pour contourner les limitations du runner. Et lorsque quelque chose casse… bonne chance pour reproduire localement ce qui s’est passé dans le cloud.
Et puis arrive Dagger 1.0.
Le vrai problème des pipelines modernes
Les outils CI/CD actuels fonctionnent par déclarations d’étapes : build, test, deploy. Chaque étape est exécutée dans un environnement souvent opaque, dépendant du runner, des variables d’environnement, des secrets injectés dynamiquement et des artefacts partagés.
Résultat : le pipeline n’est pas portable. Il est couplé à la plateforme qui l’exécute. Et pire encore, il est difficilement testable localement.
Un pipeline que tu ne peux pas exécuter localement est un pipeline que tu ne maîtrises pas.
Dagger : une autre approche
Dagger repose sur un principe simple mais radical : un pipeline doit être un programme, pas un fichier YAML.
Plutôt que de décrire des étapes statiques, tu écris ton pipeline en Go, Python ou TypeScript. Le moteur Dagger s’appuie sur BuildKit et des conteneurs isolés pour exécuter chaque étape dans un environnement reproductible.
Ton pipeline devient du code versionné, testable, exécutable localement ou dans n’importe quel système CI existant.
Exemple concret : pipeline Node.js en TypeScript
import { connect } from "@dagger.io/dagger";
async function main() {
const client = await connect();
const source = client.host().directory(".");
const node = client.container()
.from("node:20")
.withDirectory("/app", source)
.withWorkdir("/app")
.withExec(["npm", "install"])
.withExec(["npm", "test"]);
await node.stdout();
}
main();
Ce pipeline peut être exécuté localement via dagger run ou intégré dans GitHub Actions sans modification. L’environnement est identique, car il est encapsulé dans le conteneur BuildKit.
Reproductibilité totale
L’un des points forts de Dagger est la reproductibilité complète. Chaque étape est un conteneur. Chaque dépendance est explicitement définie. Chaque artefact est géré par le moteur.
Finis les “ça marche sur le runner mais pas chez moi”.
Intégration cloud native
Dagger n’est pas un orchestrateur concurrent de GitHub Actions ou GitLab CI. Il s’intègre à eux. Tu peux utiliser GitHub Actions pour déclencher l’exécution… mais le pipeline réel reste portable et indépendant.
Cela signifie que tu peux changer de plateforme CI sans réécrire tes pipelines.
Comparaison rapide : Dagger vs CI classique
- YAML statique vs code programmable
- Runner dépendant vs conteneurs isolés
- Débogage complexe vs exécution locale simple
- Couplage plateforme vs portabilité totale
Pourquoi 2026 est le bon moment
Les architectures cloud deviennent plus complexes. Les pipelines incluent des scans de sécurité, des tests d’infrastructure, des déploiements multi-régions, des builds multi-arch.
Un simple YAML ne suffit plus. Il faut une logique conditionnelle, réutilisable, versionnée proprement.
Conclusion : le CI/CD comme produit logiciel
Dagger 1.0 marque une étape importante : le pipeline devient un artefact logiciel à part entière, avec ses dépendances, ses tests et son cycle de vie.
Et dans un monde cloud natif où tout devient programmable, continuer à écrire des fichiers YAML géants commence à ressembler à une relique d’un autre temps.
