Alfa-Bank a Montré Comment des Sceptiques ont Déployé un Service RH Interne en Production avec GLM-5

Alfa Bank a partagé un cas où une équipe de sceptiques du vibe-coding a lancé un nouveau service RH en production en quelques semaines en utilisant GLM-5. L'expérience a montré que l'IA accélère considérablement le prototypage et le développement de routine, mais ne soulage pas l'équipe de la responsabilité de l'architecture, Git et du lancement.

Comment le projet a été sélectionné

Un pilote au sein de HR Tech a été réuni avec trois personnes qui ne croyaient initialement pas aux bénéfices pratiques du vibe-coding : un chef d'équipe, un analyste système et un product manager. Ils ont reçu la liberté de choisir une tâche, et l'équipe a décidé de ne pas faire un projet de démonstration abstrait, mais plutôt de prendre une fonctionnalité réelle de la feuille de route de développement d'Alfa People. C'est ainsi qu'a émergé le service "Mes Objectifs", où les employés de la banque peuvent fixer des objectifs et les lier à des tâches au sein de la plateforme RH d'entreprise.

L'enjeu était non seulement la vitesse, mais aussi un risque raisonnable. Si le projet n'avait pas décollé, il n'aurait pas rompu les processus métier critiques, mais s'il avait réussi, il aurait fermé un besoin réel. Pendant ce temps, les délais se sont rapidement resserrés : la date limite a été reportée plusieurs fois et le temps de développement s'est réduit à seulement quelques jours.

L'équipe a utilisé la découverte déjà menée, les points de douleur des utilisateurs recueillis et les solutions minimales décrites, puis a confié au modèle la tâche de préparer un brouillon des exigences commerciales.

Comment s'est déroulé le développement

En pratique, le plus difficile n'a pas été GLM-5 lui-même, mais la collaboration d'personnes qui n'avaient jamais écrit d'applications de production et n'avaient presque aucune expérience avec l'IDE et Git. Le chef d'équipe a dû d'abord faire un onboarding rapide, configurer l'environnement et expliquer les actions de base avec les branches, les pull requests et les pushes. Sans cela, l'IA accélérait effectivement certains morceaux de travail, mais tout le flux était ralenti par chaque conflit, malentendu et divergence de changements. Ensuite, le processus se présentait ainsi :

• le chef d'équipe, l'analyste système et le product manager ont travaillé sur le service
• l'interface a été assemblée via des descriptions textuelles et des séries d'itérations rapides
• l'équipe a créé 19 versions de prototype avant de choisir la base du produit
• en raison de la forte charge sur GLM-5 pendant la journée, le développement s'est souvent déplacé vers les heures nocturnes
• parmi 15 équipes pilotes, seule cette composition a réussi à amener le service à la production

L'IA a principalement aidé avec la mise en page, les formulaires, les validateurs et les versions initiales des écrans. Le product manager décrivait comment l'interface devrait être, le modèle généraient du HTML et de la logique UI, et le chef d'équipe connectait cela au backend et l'amenait à un état de fonctionnement. Après le lancement, le service a rapidement gagné en utilisation réelle : en première semaine, 10 000 utilisateurs uniques ont été enregistrés, 9 240 objectifs créés et 981 tâches liées, ce qui pour un produit interne semblait un très bon démarrage.

Où des limitations sont apparues

Le cas montre bien que le principal goulot d'étranglement du développement d'entreprise avec l'IA ne se trouve pas dans la génération de code, mais dans la discipline d'ingénierie. Quand plusieurs participants modifient simultanément le projet, le manque de connaissance de Git se transforme en travail manuel constant pour résoudre les conflits. Le deuxième problème est infrastructurel : 15 équipes ont participé au pilote en même temps, et pendant la journée GLM-5 pouvait prendre plusieurs minutes pour répondre, ce qui rendait l'outil presque inutile et perturbait le rythme de travail.

Un autre moment révélateur s'est produit juste avant la démonstration : le modèle et les plugins sont devenus indisponibles, et les bugs finaux ont dû être corrigés manuellement. Cela vous dégrise rapidement et dissipe l'illusion que l'IA peut remplacer complètement un ingénieur dans un moment critique. L'architecture, les intégrations, la sécurité, la vérification des logs et la résolution des cas limites restaient du côté du développeur expérimenté.

En fait, c'étaient précisément les corrections manuelles au dernier moment qui ont permis à la présentation et au lancement de se dérouler sans accroc.

"Dans les grandes entreprises, le vibe-coding n'est pas un

remplacement pour un développeur, mais un outil entre les mains d'un spécialiste expérimenté."

En conséquence, l'équipe est arrivée à un modèle d'utilisation plus sobre : l'IA convient au travail parallèle sur les tâches de routine, les interfaces et les hypothèses préliminaires, mais n'élimine pas le leadership technique. Si les limites de lancement ne sont pas fixées, il existe une tentation d'élargir infiniment la portée des tâches, car il semble que le modèle fasse "un petit peu plus". En pratique, c'était précisément un cadre de tâches rigide, le contrôle manuel et la capacité à arrêter les améliorations au bon moment qui ont permis de terminer le service.

Ce que cela signifie

L'histoire d'Alfa Bank est importante car elle montre le vibe-coding sans filtre publicitaire. Au sein d'une grande entreprise, il peut déjà accélérer le lancement de produits internes, particulièrement au stade du prototypage et des tâches d'UI typiques, mais cela ne fonctionne que lorsqu'il y a un ingénieur expérimenté, une portée de travail claire et une volonté de gérer manuellement tout ce qui est critique. Dans ce scénario, l'IA n'est pas un pilote automatique, mais un accélérateur d'équipe qui produit des résultats uniquement avec un processus mature et une responsabilité stricte du résultat.