Le client et le contexte
Viking Conseil conçoit des modèles de prévision de consommation électrique. L’entreprise est née d’une thèse sur la prévision adaptative, soutenue en 2022, et elle vend aujourd’hui ses prévisions à des fournisseurs d’électricité et à des gestionnaires de réseau.
Ces clients passent par une API. Chaque jour, elle reçoit les dernières mesures de consommation d’un client et met son modèle à jour. Elle reçoit ensuite les données météo des jours à venir et renvoie la prévision. Les clients ont leurs propres outils et n’utilisent que cette API.
On l’a développée en 2023, en même temps qu’une application Shiny. Depuis, on en assure la maintenance, avec un rapport envoyé chaque mois, et on la fait évoluer avec l’activité de Viking Conseil. Ses données sont stockées dans DuckDB, une base de données qui tient dans un seul fichier, et son serveur a été agrandi trois fois à mesure que les modèles et les données s’ajoutaient.
Le problème
Fin 2025, Viking Conseil a intégré plusieurs clients. Tous ont besoin de leur prévision le matin, et les appels se concentrent entre 9 h et 11 h.
Or l’API repose sur plumber, le package qui expose du code R sous forme d’API, et elle tourne dans un seul processus. Elle traite une requête à la fois, et les suivantes attendent leur tour. Les premières erreurs de délai dépassé sont apparues lors d’un test où plusieurs modèles devaient être mis à jour à la suite.
Le fondateur de Viking Conseil nous a alors demandé comment rendre l’API capable de traiter plusieurs requêtes en parallèle. On ne disposait à ce moment d’aucune mesure du temps de réponse en production.
Ce qu’on a fait
On a proposé trois étapes indépendantes : mesurer, corriger ce que les mesures montreraient, puis refondre l’architecture si le besoin restait. Viking Conseil a validé les deux premières.
Mesurer avant de refaire. Une refonte aurait fait tourner plusieurs copies de l’API en parallèle. Avant d’engager ce chantier, on voulait savoir où partait le temps d’une requête. On a donc branché l’API sur notre infrastructure de monitoring, où OpenTelemetry enregistre la durée de chaque étape d’une requête et où Grafana l’affiche dans un tableau de bord que l’équipe de Viking Conseil consulte comme nous.
Après une semaine de mesures, le détail d’une requête de prévision a montré où chercher. Elle durait 1 min 46 s, dont 18 secondes de calcul et 1 min 28 s passées à lire la base de données. L’API ouvrait et refermait la base à chacune de ses neuf lectures, et chaque passage prenait environ 9 secondes. Ce fonctionnement datait de l’époque où l’application Shiny partageait la base avec l’API.
Corriger ce que les mesures désignent. La correction tenait en deux changements, déployés à une heure creuse. L’API garde désormais une seule connexion ouverte à la base, et elle charge en une fois toutes les informations d’un client. Pour les clients de Viking Conseil, elle se présente comme avant, avec les mêmes adresses et la même clé d’accès, et ils n’ont rien eu à modifier de leur côté.
La difficulté : un effet de bord le lendemain
Le lendemain du déploiement, l’équipe de Viking Conseil a remarqué que le fichier de la base, qu’elle copie régulièrement pour ses analyses, ne contenait pas les opérations du matin. Elles n’y sont apparues qu’en début d’après-midi.
C’était une conséquence du changement de la veille. Avec une connexion ouverte en continu, la base enregistre d’abord les écritures dans un journal, puis les reporte par lots dans le fichier principal. Aucune donnée ne manquait, et les prévisions du matin étaient bien parties chez les clients. On a expliqué le mécanisme à l’équipe le jour même, et indiqué comment obtenir une copie complète.
Les résultats
Deux semaines après le déploiement, on a comparé les mesures du tableau de bord avant et après.
| Avant | Après | |
|---|---|---|
| Une prévision | 2 min 05 s | 6 s |
| Une mise à jour de modèle | 3 min 37 s | 55 s |
| Attente d’une requête avant son traitement | 26 s | 1,5 s |
| Temps que l’API passe à traiter des requêtes | 30 h par semaine | 4,5 h par semaine |
Aux heures de pointe, l’API était occupée jusqu’à 80 % du temps, et ces pics ont disparu. Le fondateur de Viking Conseil nous a confirmé que l’amélioration se voyait de son côté.
Depuis, Viking Conseil continue d’intégrer des clients et de déployer des modèles plus lourds. Le temps d’une requête est maintenant celui du calcul des modèles.
Le tableau de bord et le rapport mensuel de maintenance suivent cette hausse de charge. La troisième étape, la refonte de l’architecture, est déjà décrite, et elle sera lancée quand les mesures le demanderont.
Votre API ou votre application R ralentit quand l’usage augmente ? Écrivez-nous.
Commentaires