Pipelines CI/CD : comment Singularity debug mes échecs à ma place

J'ai complètement cessé de traquer les erreurs que mes pipelines pouvaient produire.

Ce n'est pas de la paresse, c'est un calcul. Débugger une erreur de pipeline finissait toujours par grignoter mon temps. 10 minutes, 15, 20, parfois davantage. Ouvrir l'onglet du provider, patienter le temps que les logs chargent, repérer la ligne rouge, reconstituer le contexte du commit fautif, comparer avec les runs précédents pour savoir si l'erreur est inédite, puis patcher, repousser et attendre la nouvelle exécution.

Sauf quand la réponse me sautait littéralement aux yeux, j'ai choisi de confier cette partie à l'IA sous forme de ticket. L'IA consulte l'erreur, examine les runs précédents (l'erreur est-elle nouvelle ?), parcourt les commits Git (vient-elle d'un commit récent ?), corrige, et ajoute les tests correspondants pour que le problème ne revienne plus.

Ma plus-value DevOps sur le sujet est passée d'indispensable à inutile. C'est grave ? Pas forcément. Tout le monde y gagne : le dev, le DevOps, les mises en production.

Cet article détaille comment cela fonctionne concrètement dans Singularity.

Les pipelines, en première classe dans l'ADE

Dans la plupart des stacks, les pipelines vivent à côté de l'IDE : un onglet GitHub Actions, un onglet GitLab CI, un onglet CircleCI. On les consulte quand quelque chose part en vrille, on les oublie le reste du temps. Dans Singularity, on a fait le choix inverse : les pipelines sont une vue de première classe dans l'Agentic Development Environment, au même niveau que le board kanban, l'éditeur ou le client Git.

À l'écran, on retrouve immédiatement l'essentiel :

• Les pipelines du projet, regroupées et nommées selon leur intention (Release Alpha, deploy staging, lint, etc.).
• Pour chaque pipeline : son taux de succès récent, sa durée médiane, le nombre d'exécutions, la branche cible.
• La timeline des runs, avec leur statut (passé, échoué, en cours, en attente), leur durée, et un lien direct vers les logs.
• Un bouton « Run pipeline » qui déclenche manuellement, sans quitter l'app.

Inutile d'aller fouiller l'UI du provider, sauf cas vraiment exotique. Tout ce que vous regardez 95 % du temps tient ici.

Créer une pipeline en langage naturel

Écrire un fichier YAML de CI/CD reste l'une des activités les plus universellement détestées du métier. Trop de plomberie, trop de pièges silencieux (indentation, contextes, secrets, conditions), trop d'onglets ouverts pour retrouver la syntaxe du provider. Dans Singularity, on saute carrément cette étape : vous décrivez en une phrase ce que la pipeline doit faire, et l'agent IA s'occupe du reste.

À partir d'une seule phrase, voici ce que l'agent fait pour vous :

1. Choisir le provider (GitHub Actions, GitLab CI, plateforme interne…) parmi les connexions configurées. La modale indique « Choosing among 4 connections » et l'agent appelle le MCP pipelines pour piocher la bonne.
2. Détecter le projet concerné, sa stack, ses gestionnaires de paquets et ses scripts existants.
3. Générer le YAML dans la convention du provider, en réutilisant vos secrets et environnements existants — pas de copier-coller depuis une autre pipeline.
4. Ouvrir un ticket avec le diff et un plan d'acceptation pour que vous arbitriez avant de pousser.

Vous lisez, vous arbitrez, vous validez. Le YAML reste lisible et modifiable — il n'est pas enfermé derrière une abstraction propriétaire. On conserve le format natif du provider, parce que c'est lui qui exécute, pas nous.

Une erreur de pipeline ? Un ticket.

C'est le cœur du sujet, et la fonctionnalité qui a transformé mon rapport quotidien au DevOps. Quand une pipeline échoue, on n'ouvre pas les logs à la main. On clique sur un seul bouton :

L'agent qui prend le ticket réalise, en parallèle et en quelques secondes, ce qui vous demanderait 15 minutes :

1. Il consulte la sortie du run en échec via le MCP pipelines (pipelines_get_failing_run, pipelines_get_task_log) — directement, sans dépendre d'un copier-coller humain.
2. Il interroge les runs précédents pour répondre à la question « est-ce que l'erreur est nouvelle ? ». Si la même pipeline passait hier et casse aujourd'hui, c'est un signal fort.
3. Il regarde les commits Git récents sur la branche concernée. Quel commit a introduit le problème ? Qui l'a poussé ? Le diff suspect tient en deux fichiers ou en cinquante ?
4. Il propose un correctif minimal sur la cause racine. Pas un workaround, pas un --no-verify, pas un retry de la pipeline en espérant que ça passe.
5. Il ajoute le test qui aurait attrapé l'erreur — c'est la partie qui compte le plus. Une régression sans test associé revient toujours.
6. Il rejoue la pipeline pour vérifier que ça passe, et il met le ticket en review.

Vous arbitrez le diff comme n'importe quel ticket Singularity : vous gardez, vous éditez, vous rejetez. La différence, c'est que vous n'avez pas eu à reconstruire le contexte vous-même.

Pourquoi un ticket et pas un chat

On aurait pu en faire un chat (« Hey IA, regarde mon erreur »). On ne l'a pas fait, et c'est volontaire. Un ticket apporte trois choses qu'un chat ne saura jamais donner :

• Une trace. Le ticket reste, attaché au commit et au run d'origine. Six mois plus tard, on sait pourquoi cette ligne a été ajoutée.
• Un statut. Une pipeline cassée, c'est un état du projet — pas un message. Le ticket prend ce statut et le rend visible sur le kanban.
• Du parallélisme. Trois pipelines cassent en même temps ? Trois tickets, trois agents, en parallèle, dans leurs worktrees Git isolés. Pas de file d'attente humaine.

Le ticket est aussi la seule primitive cohérente avec le reste de l'ADE. Une feature, un bug, un conflit Git, une revue de code : tout passe par des tickets atomiques. Une pipeline cassée n'a aucune raison d'être un objet à part.

Ce que ça change concrètement

Trois constats au bout de quelques semaines d'usage :

• Je ne perds plus de temps sur le débogage CI. Le temps moyen entre l'échec et la résolution est tombé de ~20 minutes à ~3 minutes de mon côté (le temps d'ouvrir le ticket en review). L'agent travaille pendant que je fais autre chose.
• La couverture de tests monte mécaniquement. Chaque ticket de pipeline cassée se termine par un test qui couvre le cas. C'est comme avoir un système qui transforme chaque incident en filet de sécurité.
• Le contexte CI/CD n'est plus un savoir tribal. N'importe qui dans l'équipe peut ouvrir un ticket sur un échec, même sans connaître le détail du YAML. L'agent traduit.

« Et la valeur du DevOps là-dedans ? »

Question légitime, et je me la suis posée moi-même. La réponse honnête : la valeur de réaction du DevOps sur les pipelines cassées est en train de devenir une commodité. Ce qui reste — et qui prend toute la place — c'est la valeur de conception :

• Penser l'architecture de déploiement (canary, blue/green, feature flags…).
• Choisir les bons providers, les bons secrets, les bonnes frontières d'isolation.
• Concevoir les hooks Git et les tests qui rendent les pipelines IA-réparables — c'est ce qui permet à la boucle de fonctionner.
• Lire les patterns d'échec récurrents (qu'aucun agent ne verra ticket par ticket) pour proposer des refactorings de fond.

La partie « je vais débugger ce log à la main » disparaît. La partie « je conçois un système qui se répare tout seul » prend la place.

Comment c'est branché sous le capot

Pour les curieux : l'agent IA n'écrit pas de code spécifique pour parler à chaque provider. Il appelle un MCP server dédié aux pipelines, exposé par Singularity, qui couvre les opérations standard :

• pipelines_list_templates — quels modèles de pipeline sont disponibles.
• pipelines_list_workspace_pipelines — quelles pipelines existent déjà dans le workspace.
• pipelines_create_on_platform — créer une pipeline chez le provider à partir du YAML généré.
• pipelines_trigger_run — relancer une pipeline.
• pipelines_get_failing_run + pipelines_get_task_log — récupérer les logs et le contexte d'un échec.
• pipelines_get_run_timeline — comparer un run à ses voisins.

Le même MCP fonctionne quel que soit le provider sous-jacent — GitHub Actions, GitLab CI, ou une plateforme interne. L'agent ne s'occupe pas de la plomberie ; il s'occupe du problème.

FAQ

Est-ce que ça remplace mon CI existant ?

Non. Singularity orchestre vos pipelines existantes — GitHub Actions, GitLab CI, plateforme interne — il ne les remplace pas. Le YAML reste chez vous, exécuté par votre provider, lisible et auditable.

Qu'est-ce qui empêche l'IA de masquer un vrai problème ?

Le contrat est explicite : pas de --no-verify, pas de retry sans diagnostic, pas de désactivation de test. L'agent doit traiter la cause racine, ajouter un test de régression, et passer le ticket en review humaine avant qu'il ne ferme. Si l'agent contourne un hook, le ticket échoue.

Et si l'agent se trompe de diagnostic ?

Le ticket arrive en review avec son raisonnement complet : l'extrait de log, les commits suspects, le diff proposé, les tests ajoutés. Vous arbitrez. Si vous rejetez, l'agent reprend avec votre feedback. C'est exactement la même boucle que pour les autres tickets de Singularity.

Ça marche sur des pipelines de déploiement, pas juste de tests ?

Oui. Le mécanisme est identique — l'agent lit l'échec, regarde les commits, propose un correctif. Sur des déploiements, on garde évidemment l'humain dans la boucle au moment de la promotion en production. Le ticket sert de revue de pré-MEP.

Mon équipe DevOps perd-elle son boulot ?

Non. Elle perd la partie répétitive et frustrante (lire des logs YAML à 22h). Elle garde — et reprend — la partie noble : architecturer, sécuriser, automatiser ce qui ne l'est pas encore. Concrètement, on observe surtout un rééquilibrage entre dev et DevOps, pas un remplacement.

Singularity, le produit maison de Meteor Factory

Singularity est l'environnement de développement agentique conçu et utilisé au quotidien par Meteor Factory. Découvrez Singularity et testez-le gratuitement sur singularity.meteorfactory.dev.