J'ai arrêté de debugger mes pipelines — voilà comment Singularity s'en occupe à ma place

J'ai complètement arrêté de chercher les erreurs que pouvaient générer mes pipelines.

Pas par flemme. Par calcul. Débugger une erreur de pipeline, ça pouvait me prendre du temps. 10 minutes, 15, 20, parfois plus. Le temps d'ouvrir l'onglet du provider, d'attendre que les logs chargent, de chercher la ligne rouge, de comprendre le contexte du commit qui a poussé l'erreur, de comparer avec les runs précédents pour savoir si c'est nouveau, puis de patcher, repush, attendre la nouvelle exécution.

À moins que la réponse me saute aux yeux en un coup d'œil, j'ai décidé de déléguer cette partie à l'IA via un ticket. L'IA consulte l'erreur, regarde les runs précédents (l'erreur est-elle nouvelle ?), consulte les commits Git (vient-elle d'un commit récent ?), corrige, et ajoute les tests correspondants pour que ça ne se reproduise 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 explique comment ça marche 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.

Sur l'écran, on voit immédiatement les choses utiles :

• Les pipelines du projet, regroupées et nommées avec 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.

Pas besoin d'aller voir l'UI du provider sauf cas vraiment exotique. Tout ce que vous regardez 95 % du temps est là.

Créer une pipeline en langage naturel

Écrire un fichier YAML de CI/CD, c'est 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 de tabs ouverts pour aller chercher la syntaxe du provider. Dans Singularity, on saute cette étape : vous décrivez en une phrase ce que la pipeline doit faire, et l'agent IA s'occupe du reste.

Ce que l'agent fait pour vous, à partir d'une seule phrase :

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 caché derrière une abstraction propriétaire. On reste sur 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 c'est la fonctionnalité qui a changé 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 fait, en parallèle et en quelques secondes, ce que vous feriez en 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 de 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 dû 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 choses dont je me suis rendu compte au bout de quelques semaines :

• 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 l'ai eue 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.

Pour aller plus loin

Singularity est en bêta fermée. Pour comprendre la philosophie produit qui sous-tend tout ça — pipelines, Git, kanban — lisez le manifesto. Pour rejoindre la liste d'attente, l'inscription est ici.