Deep learning : comment Batch a réduit son temps de calcul de 2h30 à 20 minutes avec Claude

Data & Tech

23 Jul 2026 · Rédigé par Hervé Lourdin

Comment réduire le temps de calcul d'un modèle de deep learning sans changer de modèle ? En mesurant précisément où la charge de calcul est mal exploitée, plutôt qu'en cherchant à simplifier l'algorithme : chez Batch, cette approche a permis de réduire le temps de calcul du score de prédiction de churn de 2h30 à 20 minutes, avec Claude comme copilote technique tout au long du chantier.

Ce gain vient d'un travail mené par l'équipe machine learning de Batch, avec Claude comme copilote technique à chaque étape. Il illustre un usage concret de l'IA générative, loin des discours abstraits : accélérer l'optimisation des modèles qui alimentent les scores prédictifs d'une plateforme CRM.

À retenir

Le score de churn (RNN) est passé de 2h30 à 20 minutes de calcul par itération, sans changer de modèle
La cause n'était pas la complexité de l'algorithme mais la sous-exploitation des ressources de calcul
L'équipe a d'abord construit un labo de mesure isolé et instrumenté avant d'optimiser quoi que ce soit
Claude a servi de copilote technique (structuration des essais, reporting automatisé, corrélation code/système), sans remplacer l'expertise data science
Le cycle d'itération passe de 2 essais par jour à plusieurs dizaines ; la méthode est réutilisable sur d'autres modèles de Batch Predict

Le score de churn, un modèle juste mais beaucoup trop lent

Le score de churn évalue, pour chaque client, la probabilité et le moment le plus probable de son désabonnement. Techniquement, c'est un réseau de neurones récurrent (RNN), une famille de modèles de deep learning conçus pour analyser des séquences, ici l'historique d'un client dans le temps.

Sur le fond, le modèle faisait ce qu'on attendait de lui : ses prédictions étaient justes. Le problème, c'était le temps de calcul. Une itération d'entraînement prenait environ 2h30, même sur un poste local correctement équipé.

Concrètement, un data scientist pouvait lancer 2 essais par jour au mieux, entre le lancement du calcul, l'attente, l'analyse des résultats et l'ajustement des paramètres. Un cycle aussi long rend impossible tout travail exploratoire sérieux. Il pèse aussi directement sur les délais et les coûts liés à l'arrivée d'un nouveau client sur ce score.

Un problème de ressources, pas de complexité

Bon à savoir

Un temps de calcul trop long fait souvent penser à un problème d'algorithme, ici, ce n'était pas le cas.

Le vrai sujet, c'était la sous-exploitation des ressources de calcul. Les opérations réalisées par le modèle restaient relativement simples, mais la charge n'était pas répartie ni optimisée pour le matériel disponible. Un moteur puissant qui tournerait en permanence sur le premier rapport : la puissance est là, mais elle n'est pas exploitée.

Cette distinction change tout dans la façon d'aborder le problème. On ne cherche plus à simplifier le modèle, on cherche à mieux utiliser la machine qui le fait tourner.

La méthode : construire un labo de mesure avant d'optimiser

Plutôt que d'ajuster des paramètres au hasard, l'équipe a d'abord construit un environnement de test isolé : une sandbox sur une machine dédiée, entièrement instrumentée.

Cette étape avait un objectif précis : mesurer ce qu'un environnement cloud géré classique ne laisse jamais voir. Sans cette visibilité, impossible de savoir si le ralentissement venait du modèle lui-même, de la façon dont les données transitaient vers le GPU (le processeur spécialisé dans les calculs de deep learning), ou d'un déséquilibre entre le temps de préparation des données et le temps de calcul pur.

C'est cette étape de construction, souvent négligée, qui a permis ensuite de savoir précisément où intervenir. Sans labo de mesure, toute optimisation revient à deviner.

Ce que Claude a changé dans le processus

Une fois l'environnement de mesure en place, Claude a eu un accès complet à la machine. Un mode de fonctionnement possible uniquement parce que l'environnement était isolé et sans risque pour la production. Quatre apports concrets ressortent de ce chantier :

Structurer les expérimentations. Chaque essai a été documenté par Claude dans un cahier de recherche : hypothèse testée, mesures relevées, résultat, comparaison avec les tentatives précédentes. Une succession de tests jusque-là un peu artisanale est devenue une démarche traçable.
Automatiser le reporting. Claude générait le rapport de chaque expérimentation, une tâche chronophage qui prenait auparavant un temps précieux à l'équipe.
Croiser le code et le comportement du système. Claude analysait la corrélation entre l'exécution du code et le comportement matériel, pour aider à isoler le facteur limitant réel dans la chaîne de calcul.
Accélérer la validation d'hypothèses, sans remplacer l'expertise. Claude ne « sait » pas magiquement quel paramètre changer. Ce sont les data scientists de Batch qui ont identifié les leviers à tester. La valeur de Claude tient dans la vitesse et la profondeur d'exploration, pas dans une intuition qu'il aurait sur le sujet.

Attention : ce point conditionne tout le reste. Un modèle d'IA générative accélère l'exploration, il ne se substitue pas à l'expertise data science. Les deux fonctionnent ensemble, pas l'un à la place de l'autre.

Résultat : de 2h30 de calcul à 20 minutes, un cycle d'itération enfin viable

Le score, qui tournait initialement sur environ 2h30, tient désormais dans une fenêtre de calcul de 20 minutes. Le coût de calcul associé a diminué dans les mêmes proportions.

Au-delà du chiffre, ce chantier a produit trois bénéfices durables :

Un cycle d'itération viable pour l'équipe data science, avec plusieurs essais possibles par jour au lieu de 2
Une traçabilité complète des expérimentations : hypothèses, mesures et résultats de chaque essai, plutôt que des tests dispersés
Une méthode réutilisable pour de futurs chantiers de performance, même si l'optimisation elle-même n'est pas transposable telle quelle à un autre modèle

Ce que ça change pour les équipes CRM

Un cycle d'itération plus court permet aux équipes Batch de construire un score de prédiction de churn fiable. Un temps de calcul réduit change aussi la donne côté CRM : les prédictions peuvent être recalculées plus souvent. Résultat, des campagnes de rétention pilotées plus finement, au bon moment.

La méthode documentée ici (labo de mesure isolé, expérimentation structurée, IA comme copilote technique) s'applique aussi à d'autres modèles prédictifs utilisés dans Batch Predict, du scoring d'engagement à la recommandation de contenu.

Chez Batch, l'IA générative est utilisée comme un outil d'ingénierie interne pour fiabiliser et accélérer les modèles qui alimentent les scores prédictifs de la plateforme, dont le score de churn.