Vous poussez un correctif un vendredi à seize heures. Le samedi matin, les alertes retentissent. Vous remontez l'incident jusqu'à une pull request fusionnée dix-huit heures plus tôt. La branche a compilé, les tests sont passés, mais la description de la PR est vide. Aucun élément de travail n'y est lié. L'historique des approbations ne montre rien. Vous faites face à une fusion fantôme, et vous passez maintenant votre week-end à nettoyer un désastre qui aurait dû être intercepté avant d'atteindre la branche principale.

Les petites équipes vivent avec ce risque au quotidien. Vous n'avez pas de responsable des mises en production qui surveille chaque fusion. Vous n'avez pas d'équipe plateforme qui construit des moteurs de politiques sur mesure. Ce que vous avez, c'est Azure DevOps, et ses politiques de branche intégrées sont un outil peu nuancé. Soit elles ferment la porte brusquement, soit elles l'ouvrent en grand. Exigez deux réviseurs et vous bloquez les correctifs urgents. Relâchez les règles et des descriptions vides s'envolent vers la production aux côtés de changements non documentés. Il y a rarement un juste milieu.

Cet écart est précisément la raison pour laquelle nous avons créé Gatekeeper. C'est une plateforme de revue de PR assistée par l'IA, conçue spécifiquement pour Azure DevOps, mais oubliez tout ce que vous pensez savoir sur les outils de développement modernes. Il n'y a pas de conteneur Docker, pas d'abonnement, et pas de pipeline de déploiement cloud. Gatekeeper est un fichier HTML unique. Vous l'ouvrez dans votre navigateur, vous saisissez quatre valeurs, et vous appuyez sur un bouton. L'outil répond ensuite à trois questions simples : Cette PR est-elle liée à un ticket ? Un humain l'a-t-il réellement révisée ? Et la qualité du code est-elle satisfaisante ?

La décision de tout emballer dans un seul fichier autonome n'était pas un gadget. Cela résout de réels casse-têtes opérationnels. Premièrement, il n'y a aucune infrastructure à héberger ou à payer. Vous ne provisionnez pas un App Service et vous ne vous souciez pas des coûts d'egress. Deuxièmement, les identifiants ne quittent jamais votre machine. Votre jeton d'accès personnel Azure DevOps réside uniquement dans la mémoire du navigateur et disparaît dès que vous actualisez la page. Il n'y a pas de base de données de secrets à divulguer et pas de serveur OAuth à laquelle faire confiance. Troisièmement, l'adoption se fait sans friction. Vous n'avez besoin d'onboarder personne via un wiki. Vous joignez le fichier à un e-mail ou vous le déposez dans un fil Slack. Le destinataire l'ouvre et commence la révision immédiatement.

La couche de faits : le déterminisme avant tout

Gatekeeper divise sa revue en deux couches distinctes, et cette séparation est la colonne vertébrale de sa fiabilité.

La première couche est du JavaScript pur communiquant directement avec l'API REST d'Azure DevOps. Elle vérifie des faits immuables. Soit une pull request est liée à un élément de travail, soit elle ne l'est pas. Soit un réviseur a émis un vote d'approbation, soit il ne l'a pas fait. La description est soit vide, soit elle contient de véritables phrases. Les discussions actives sont soit résolues, soit elles sont encore en suspens.

Plus précisément, la couche de faits recherche quatre éléments :

  • Correspondance des tickets : La PR est-elle liée à au moins un élément de travail ?
  • Validation du réviseur : Quelqu'un a-t-il voté pour approuver, ou le compte est-il toujours à zéro ?
  • Qualité de la description : La description est-elle vide ou s'agit-il d'un simple texte de remplacement ?
  • Discussions ouvertes : Y a-t-il des fils de commentaires non résolus en attente d'une réponse ?

Ces vérifications produisent des tampons visuels sur la page. Un grand tampon rouge NOT MAPPED est difficile à ignorer. Une fine coche verte nichée dans une cellule de tableau est facile à manquer. Nous avons appris très tôt que les défaillances de processus doivent être explicites. Lorsqu'un développeur se précipite pour fusionner, la subtilité ne fonctionne pas. La couche de faits existe pour éliminer toute ambiguïté.

Parce que cette couche repose sur des réponses d'API déterministes, sa précision est absolue. Si le tampon indique NO APPROVAL, vous pouvez parier que personne n'a cliqué sur le bouton d'approbation. S'il indique UNRESOLVED THREADS, la conversation est toujours en cours. Cette couche ne