Vercel

Vercel expose plusieurs types d'objets via son API REST : déploiements, projets, membres d'équipe, domaines et groupes d'accès. Cette intégration se concentre exclusivement sur les déploiements, qui représentent l'unité fondamentale de livraison dans Vercel et le seul type d'objet portant une attribution directe par ingénieur via le champ creator. Les projets appartiennent à l'équipe et n'exposent pas de créateur individuel au niveau de l'endpoint de liste ; les domaines et groupes d'accès reflètent la configuration de l'infrastructure plutôt que l'activité d'ingénierie. Cinq KPIs ont été retenus parmi onze candidats, sélectionnés selon trois critères : capacité d'attribution à un propriétaire, résistance au gaming et équilibre entre indicateurs avancés et retardés.

Vélocité de livraison : lire la fréquence à l'aune de la rapidité

Production Deployments comptabilise le nombre de déploiements ayant atteint l'état prêt dans l'environnement de production, attribués à l'ingénieur qui les a déclenchés. Average Lead Time mesure le temps écoulé entre le déclenchement d'un déploiement et le moment où il devient disponible en production. Ces deux indicateurs correspondent directement aux deux premiers métriques DORA — fréquence de déploiement et délai de livraison des changements — et leur relation révèle davantage que chacun ne mesure séparément. Un nombre élevé de Production Deployments associé à un Average Lead Time long identifie un schéma de livraisons fréquentes mais lentes : l'ingénieur déploie souvent, mais le pipeline introduit une latence significative avant que le code n'atteigne les utilisateurs. Le schéma inverse, faible fréquence avec délai court, peut indiquer des livraisons peu fréquentes mais bien optimisées, ou une sous-utilisation des capacités de déploiement de Vercel. La combinaison des deux cadre la cadence de déploiement plus précisément qu'aucun indicateur seul.

Qualité de livraison : neutraliser le risque de gaming sur la fréquence

Production Deployments porte un risque de gaming direct : un ingénieur incité sur la fréquence de déploiement peut artificiellement gonfler ce chiffre en fractionnant les changements en de nombreux petits déploiements à faible risque ou en redéclenchant inutilement des déploiements. Trois indicateurs de qualité sont associés à cet indicateur avancé précisément pour neutraliser ce risque.

Deployment Success Rate mesure la proportion des tentatives de déploiement qui réussissent, en excluant les déploiements annulés du dénominateur. Ces derniers sont exclus parce que les systèmes d'intégration continue annulent souvent des builds en cours lorsqu'un nouveau commit les supplante ; imputer une annulation à l'ingénieur pénaliserait un comportement standard d'intégration continue plutôt qu'un problème de qualité. Build Error Count isole les déploiements échoués en valeur absolue, ce qui complète le ratio : un ingénieur avec un faible taux d'erreur mais un volume élevé peut tout de même générer un nombre absolu significatif d'erreurs. Rollback Count capture les incidents après coup, lorsqu'un déploiement en production est explicitement annulé pour revenir à une version antérieure. Là où Deployment Success Rate et Build Error Count mesurent ce qui échoue avant d'atteindre les utilisateurs, Rollback Count mesure ce qui échoue après — c'est l'approximation la plus proche du temps moyen de rétablissement que les données Vercel permettent. Lire les trois ensemble trace le profil qualité complet de l'activité de déploiement d'un ingénieur : fréquence des défaillances, gravité des défaillances et fréquence des rétablissements post-incident.

Périmètre et limites de l'intégration

Vercel capture la couche déploiement de la chaîne de valeur de l'ingénierie, et rien en amont. La revue de code, le cycle time des pull requests, la planification des sprints et le cadrage des fonctionnalités sont invisibles pour cette intégration ; une vision complète de la performance d'ingénierie nécessite des données complémentaires provenant d'outils comme GitHub ou Linear. Dans son périmètre, Vercel enregistre les événements de déploiement mais ne mesure pas la qualité de ce qui est déployé : un déploiement en production réussi peut correspondre à une fonctionnalité robuste ou à un changement de configuration trivial, et l'API ne distingue pas les deux. La durée moyenne de build a été évaluée comme KPI candidat et rejetée : elle est manipulable par un fractionnement adversarial des commits pour réduire la durée mesurée par déploiement, ce qui la rend inadaptée à un usage OKR. La fiabilité des cinq KPIs dépend d'une utilisation cohérente de l'environnement cible production par l'équipe. Les équipes qui déploient en production via des mécanismes alternatifs hors de Vercel — commandes d'infrastructure directes, pipelines CI qui contournent Vercel — produiront une attribution incomplète, et les indicateurs sous-estimeront le volume de livraison réel.