Vibe coding observabilité : que vérifier avant la prod

Un lundi matin, une équipe merge un export de commandes écrit presque entièrement par un assistant de code. Les tests passent, la revue ne montre rien d’anormal, l’endpoint répond 200. Trois semaines plus tard, un client se plaint de lignes manquantes dans son fichier. Voilà le vrai sujet du vibe coding observabilité : non pas « l’IA code-t-elle bien ? », mais « qu’est-ce qui me prouve, en production, que ce code fait ce que je crois ? ».

Je pars de ce problème d’exploitation plutôt que d’une liste de fonctions. Trois décisions : où placer les spans, quoi regarder dans Dynatrace SaaS, et quoi exiger avant un merge. Pour le point de vue de l’éditeur, voyez son billet sur le runtime ; le plan et les exemples ci-dessous sont les miens.

Méthode : j’ai exécuté le code Python des captures avec opentelemetry-sdk 1.45.2 (sortie réelle montrée). Je n’ai pas lancé les requêtes DQL ni envoyé de données à un environnement Dynatrace : elles sont marquées « non vérifié ». Tout vaut pour Dynatrace SaaS ; Managed n’est pas traité.

Pourquoi le vibe coding observabilité n’est pas un sujet à part

Un assistant produit du code plausible. Il compile, il passe les tests qu’il a lui-même écrits, il gère le cas nominal. Ce qui lui manque, c’est la connaissance de votre production : volumes réels, données sales, dépendances lentes. Ce n’est pas un défaut moral, c’est un angle mort contractuel : personne ne lui a donné ce contexte.

Je ne cite aucun chiffre sur la qualité du code généré, car je n’ai pas lu d’étude que je puisse vérifier. Le raisonnement tient sans cela : plus on accepte de code que l’on n’a pas écrit ligne à ligne, plus la preuve doit venir de l’exécution et non de la lecture. C’est de l’hygiène SRE classique : un SLI mesuré vaut mieux qu’une confiance déclarée.

Ne confondez pas deux chantiers. Superviser l’assistant lui-même (coûts, usage, sessions) est traité dans superviser un agent de code. Ici, il s’agit du code livré par l’assistant, une fois en production. Et pour la prise en main d’un IDE assisté, l’article sur ThinkRail reste un autre sujet.

Le cas d’école : 200 OK et 25 % de lignes perdues

J’ai reconstitué le scénario en vingt lignes. La fonction fait ce que les assistants font souvent : une boucle sur les commandes, une requête par commande pour retrouver le client, et un try/except qui avale toute erreur pour que l’export « ne plante jamais ».

Deux défauts classiques se cachent là. Le premier : une requête par commande, soit 1 + 40 requêtes pour 40 lignes. Le second : l’exception est ignorée, donc la réponse reste verte. Voici l’exécution réelle.

• La réponse annonce un succès, mais 10 commandes sur 40 manquent : un client absent de la table.
• La trace compte 41 spans pour une seule requête HTTP : la signature d’un N+1.
• Le span racine reste UNSET, donc un SLI calculé sur lui seul ne verrait rien.
• Les 10 spans enfants, eux, portent ERROR et le message : c’est là que la vérité s’est déposée.

Première décision : instrumenter la couche basse, pas le handler

La leçon du test est architecturale. Le span a enregistré l’erreur parce que l’exception a traversé le bloc with de query_one, avant que le code appelant ne la fasse taire. Si j’avais seulement entouré le handler, j’aurais eu un span vert.

Règle pratique : placez les spans au plus près des appels sortants (base, HTTP, file de messages), là où le code généré ne peut pas les masquer en attrapant tout. Les bibliothèques d’instrumentation OpenTelemetry le font souvent pour vous ; je n’ai pas vérifié lesquelles couvrent votre pilote. Pour savoir ce qu’un span contient, lisez l’anatomie d’un span OpenTelemetry.

Deuxième règle : interdisez dans la revue les except Exception: pass sans journalisation ni compteur. Ce n’est pas du purisme. C’est la ligne qui fabrique des incidents invisibles.

Envoyer la télémétrie vers Dynatrace SaaS

D’après la page OTLP de la documentation, l’endpoint SaaS est https://{id-environnement}.live.dynatrace.com/api/v2/otlp, avec /v1/traces pour les traces. L’authentification passe par l’en-tête Authorization: Bearer et un jeton portant le scope openpipeline:traces:ingest. Le transport est HTTP en Protobuf binaire : ni gRPC ni JSON. Réglez donc OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf, ou passez par un Collector qui convertit.

Si vous copiez l’identifiant depuis la barre d’adresse, retirez le .apps du nom d’hôte. Le jeton se range dans un coffre, jamais dans le prompt de l’assistant ni dans le dépôt. Pour un Collector complet, voyez le Collector OpenTelemetry vers Dynatrace.

Je n’ai pas testé cette ingestion de bout en bout. Et je ne sais pas si les données de votre contrat les facturent différemment : non vérifié, relisez votre licence.

Deuxième décision : trois questions à poser aux traces

Une fois les spans reçus, ne cherchez pas « tout ». Posez trois questions, dans cet ordre.

1. Combien de spans par trace ? Une requête simple qui en compte des dizaines trahit un N+1 ou une boucle.
2. Quels spans enfants sont en erreur alors que la racine est verte ? C’est le motif de notre export.
3. Quelles opérations ont changé de durée après le dernier déploiement ? Un code regénéré peut remplacer un index par un balayage complet sans qu’aucun test le voie.

Pour la première, une requête DQL à adapter (non vérifiée sur un environnement réel) :

fetch spans, from: now()-2h
| summarize spans = count(), by: {trace.id}
| sort spans desc
| limit 10

Pour la deuxième, le détail des exceptions se lit dans les événements de span : la requête testée par la documentation est décrite dans les exceptions OpenTelemetry dans les traces. Comparez ensuite la valeur obtenue avec le taux d’erreur de la racine : l’écart mesure ce que votre code cache.

Le billet de l’éditeur évoque aussi des outils pour amener ce contexte runtime dans l’IDE via MCP et pour inspecter une application sans la redéployer. Je ne les ai pas essayés ici : voyez l’installation du serveur MCP Dynatrace SaaS avant de promettre quoi que ce soit à votre équipe.

Troisième décision : une porte de merge, pas un audit permanent

Un contrôle qui ne coûte rien se fait. Voici une porte minimale, à adapter :

• Toute fonction qui appelle une base ou une API distante est couverte par un span, nommé selon l’opération et non selon le fichier.
• Aucun except large sans compteur ou log avec identifiant de trace.
• Un test de charge court sur un jeu de données réaliste, avec un plafond du nombre de spans par requête.
• Un SLI défini avant le merge (taux de lignes exportées, latence p95), même rudimentaire.

Ce dernier point est le plus rentable. Dans notre export, un simple compteur « lignes attendues contre lignes écrites » aurait suffi à voir 75 % de réussite dès le premier jour.

Ce qui peut mal tourner

• Un assistant peut aussi supprimer ou affaiblir vos spans en « nettoyant » le code : verrouillez-les par un test.
• Instrumenter tout produit beaucoup de données ; échantillonnez au besoin, en sachant que cela efface une partie des cas rares.
• Les messages d’exception peuvent contenir des données personnelles : à relire avant d’envoyer vers un SaaS. Voyez aussi les services IA vulnérables pour l’angle sécurité.
• Mon exemple est volontairement caricatural : un code réel cumule rarement tous les défauts, mais il en cumule souvent deux.

Bonnes pratiques

• Instrumentez les appels sortants avant d’écrire le premier prompt de fonctionnalité.
• Comparez toujours le statut de la racine et celui des enfants.
• Mesurez un résultat métier, pas seulement le code HTTP.
• Gardez la revue humaine : l’observabilité détecte, elle ne remplace pas la lecture.

Questions fréquentes

Le vibe coding observabilité demande-t-il un outil spécifique ?

Non : ce sont les mêmes spans, métriques et logs OpenTelemetry que pour n’importe quel code. Ce qui change, c’est la discipline : on part du principe que le code accepté n’a pas été relu ligne à ligne.

Faut-il distinguer code généré et code écrit à la main dans Dynatrace ?

Je n’ai trouvé aucun champ natif qui l’indique. Si vous voulez le suivre, ajoutez un attribut de ressource ou un tag de déploiement que vous maîtrisez : c’est une convention d’équipe, pas une fonction vérifiée.

Cela fonctionne-t-il sur Dynatrace Managed ?

Je n’ai lu que la documentation SaaS (endpoint OTLP, scopes de jeton). Pour Managed, vérifiez la page correspondante avant de réutiliser ces réglages.

Conclusion

Un code généré se juge à l’exécution : instrumentez la couche basse, comparez racine et enfants, exigez un SLI avant le merge. Commencez par un seul service, mesurez le nombre de spans par requête, et regardez ce que l’exécution vous apprend que la revue n’a pas montré.

span.observer est un blog indépendant de la communauté, non affilié à Dynatrace LLC. Les marques citées appartiennent à leurs propriétaires. Les outils évoluent vite : vérifiez les commandes et options dans la documentation officielle.