Alfa-Bank raconte comment des sceptiques ont mis en production un service RH interne avec GLM-5

Alfa-Bank a partagé un cas où une équipe de sceptiques du vibe coding a mis en production un nouveau service RH en quelques semaines grâce à GLM-5. L'expérience montre que l'IA accélère nettement le prototypage et le développement routinier, mais ne décharge pas l'équipe de sa responsabilité sur l'architecture, Git et la mise en production.

Comment le projet a été choisi

Le pilote au sein de HR Tech a réuni trois personnes qui ne croyaient pas, au départ, à l'utilité pratique du vibe coding : un tech lead, un analyste système et un product manager. Libres de choisir la tâche, elles ont décidé de ne pas bâtir un projet de démonstration abstrait, mais de prendre une fonction réelle de la feuille de route d'Alfa People. Ainsi est né le service « Mes objectifs », où les salariés de la banque peuvent fixer des objectifs et y rattacher des tâches au sein de la plateforme RH de l'entreprise.

Le pari ne portait pas seulement sur la vitesse, mais aussi sur un risque raisonnable. Si le projet échouait, il ne casserait aucun processus métier critique ; s'il réussissait, il répondrait à un besoin réel. Les délais se sont pourtant vite resserrés : l'échéance a été avancée à plusieurs reprises et il ne restait que quelques jours pour développer. L'équipe a exploité le discovery déjà réalisé, les points de douleur recueillis auprès des utilisateurs et les solutions minimales décrites, puis a confié au modèle la rédaction d'un brouillon des exigences métier.

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

En pratique, le plus difficile n'a pas été GLM-5 lui-même, mais le travail commun de personnes qui n'avaient jamais écrit d'applications et utilisaient à peine un IDE ou Git. Le tech lead a dû d'abord assurer un onboarding rapide, configurer l'environnement et expliquer les gestes de base : branches, pulls et pushes. Sans cela, l'IA accélérait bien certaines tâches, mais tout le flux ralentissait à chaque conflit, malentendu ou désaccord entre modifications.

Le processus se présentait ensuite ainsi :

• le tech lead, l'analyste système et le product manager travaillaient sur le service
• l'interface a été construite à partir de descriptions textuelles et de séries d'itérations rapides
• l'équipe a réalisé 19 versions du prototype avant de retenir la base du produit
• en raison de la forte charge sur GLM-5 en journée, le développement basculait souvent sur les heures de nuit
• parmi les 15 équipes pilotes, c'est précisément celle-ci qui a réussi à mettre son service en production

L'IA a surtout aidé pour la mise en page, les formulaires, les validateurs et les premières versions des écrans. Le product manager décrivait l'interface souhaitée, le modèle générait le HTML et la logique d'UI, et le tech lead la reliait au backend et la menait à un état fonctionnel.

Après la mise en production, le service a rapidement trouvé son public : en première semaine, il a enregistré 10 mille utilisateurs uniques, 9240 objectifs créés et 981 tâches liées, ce qui ressemblait à un démarrage très solide pour un produit interne.

Où sont apparues les limites

Le cas montre bien que le principal goulot d'étranglement du développement en entreprise avec l'IA n'est pas la génération de code, mais la discipline d'ingénierie. Quand plusieurs participants modifient le projet en parallèle, l'ignorance de Git se traduit par un travail manuel permanent de résolution de conflits.

Le second problème tenait à l'infrastructure : 15 équipes participaient simultanément au pilote et, en journée, GLM-5 pouvait mettre plusieurs minutes à répondre, ce qui rendait l'outil presque inutile et cassait le rythme de travail. Un autre moment révélateur est survenu juste avant la démo : le modèle et les plugins sont devenus indisponibles, et les derniers bugs ont dû être corrigés à la main. Cela ramène vite les pieds sur terre et dissipe l'illusion que l'IA pourrait remplacer entièrement l'ingénieur au moment critique.

L'architecture, les intégrations, la sécurité, la vérification des logs et le traitement des cas limites sont restés du ressort du développeur expérimenté. De fait, c'est la retouche manuelle de dernière minute qui a permis de passer la présentation et la mise en production sans accroc.

«

Dans les grandes entreprises, le vibe coding ne remplace pas le développeur, c'est un outil entre les mains d'un spécialiste expérimenté ».

L'équipe en est venue à un modèle d'usage plus sobre : l'IA convient pour travailler en parallèle sur les tâches routinières, les interfaces et les hypothèses préliminaires, mais n'abolit pas le leadership technique. Si les limites de la livraison ne sont pas fixées, on est tenté d'élargir indéfiniment le périmètre, parce qu'on a l'impression que le modèle « fera encore un tout petit peu plus ». En pratique, un cadre de tâches strict, un contrôle manuel et la capacité d'arrêter les retouches à temps ont permis d'aller au bout.

Ce que cela signifie

L'histoire d'Alfa-Bank compte parce qu'elle montre le vibe coding sans filtre publicitaire. Dans une grande entreprise, il peut déjà accélérer le lancement de produits internes, surtout au stade des prototypes et pour les tâches d'UI classiques, mais il ne fonctionne que là où il y a un ingénieur expérimenté, un périmètre clair et la volonté de traiter à la main 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 n'apporte de résultat qu'avec un processus mûr et une responsabilité stricte sur le résultat.