Mesurer la performance avant d’ajouter une couche d’IA

L'essentiel à retenir

Ajouter de l’IA sur un système lent ne supprime pas son goulot d’étranglement. Cela peut simplement le rendre plus cher, plus variable et plus difficile à diagnostiquer. Silo offre un bon support pour apprendre la démarche inverse : formuler une hypothèse d’architecture, construire un test reproductible, mesurer le débit et la contention, puis décider où intervenir.

Le projet est un moteur de stockage en mémoire multicœur écrit en C++. Il accompagne le papier de recherche « Speedy Transactions in Multicore In-Memory Databases », présenté à SOSP en 2013. Son dépôt fournit des modes orientés performance ou débogage, une vérification optionnelle des invariants, des tests et des benchmarks, dont une charge transactionnelle TPC-C multithread. Le code est publié sous licence MIT.

La limite est nette : le README qualifie Silo de travail en cours, et le dernier push du dépôt remonte à 2017. Pour une PME belge de 10 à 50 personnes, ce n’est pas un socle à installer en production. C’est un laboratoire de recherche à utiliser sur des données fictives pour apprendre à mesurer avant d’acheter du matériel, de réécrire un service ou de poser une couche d’IA sur un problème encore mal compris.

Le problème que ça résout

Une application ralentit. La première réaction consiste souvent à ajouter quelque chose : davantage de mémoire, une nouvelle base, un cache, une file de messages, un service séparé ou, désormais, une couche d’IA chargée d’optimiser, de prédire ou de router les demandes.

Cette réaction part d’une intuition plausible. Elle ne part pas forcément d’une mesure.

Dans une PME, le symptôme arrive rarement sous la forme d’un diagnostic propre. Les utilisateurs parlent d’un écran lent. Le support observe des délais irréguliers. Un développeur soupçonne la base de données. Un autre pense que le réseau est responsable. Entre-temps, la direction reçoit une proposition pour « moderniser l’architecture » ou ajouter un assistant capable d’absorber une partie du flux.

Le risque n’est pas seulement de choisir le mauvais outil. Il est de modifier plusieurs variables à la fois, puis d’attribuer l’amélioration ou la dégradation à la dernière technologie ajoutée. Si le volume de données, le nombre de threads, le schéma d’accès et la logique applicative changent ensemble, le résultat devient difficile à expliquer. Une démonstration peut sembler rapide sans révéler ce qui se passera quand plusieurs opérations se disputent les mêmes ressources.

Silo est intéressant parce qu’il réduit le sujet à une question de système : comment des transactions concurrentes se comportent-elles lorsque plusieurs cœurs travaillent en même temps sur des données en mémoire ? Cette question ne couvre pas toute l’architecture d’une PME. Elle force toutefois une discipline utile : isoler un mécanisme, produire une charge, observer les collisions et comparer des résultats obtenus dans les mêmes conditions.

Avant d’ajouter de l’IA, cette discipline permet de distinguer trois situations. Le système manque réellement de capacité. L’architecture crée de la contention. Ou le problème se trouve ailleurs, par exemple dans une dépendance externe, une requête mal conçue ou un processus métier qui attend une validation humaine. L’IA peut être pertinente dans certains cas. Elle ne devrait pas servir à éviter le diagnostic.

Ce que c'est concrètement

Silo est un prototype de moteur de stockage transactionnel en mémoire, conçu pour étudier l’exécution sur plusieurs cœurs. Il est associé à une publication de recherche de 2013 consacrée à la vitesse des transactions dans les bases de données multicœurs en mémoire. Le dépôt permet donc de passer du papier à une implémentation observable.

Le code est écrit en C++ et publié sous licence MIT. Le projet prévoit deux orientations de construction. L’une privilégie la performance et les optimisations. L’autre facilite le débogage. Une option permet aussi de vérifier davantage d’invariants pendant l’exécution. Cette séparation rappelle une règle souvent oubliée : un environnement conçu pour comprendre un défaut n’est pas forcément celui qui donne la meilleure mesure de vitesse.

Le dépôt contient une suite de tests et plusieurs bancs d’essai. Parmi eux figure TPC-C en mode multithread, une charge transactionnelle destinée à exercer plusieurs opérations concurrentes. Le projet utilise par défaut un index arborescent concurrent. Ces éléments permettent d’observer le système sous charge, de comparer des configurations et de chercher le point où l’ajout de parallélisme cesse d’améliorer le résultat.

Ce que Silo ne fournit pas compte autant que ce qu’il contient. Le README le présente explicitement comme un travail en cours. Le dernier push du dépôt date de 2017. L’absence d’activité récente ne prouve pas que les idées du papier sont devenues fausses. Elle interdit simplement de traiter le dépôt comme un produit actuel avec maintenance, correctifs, support et trajectoire d’exploitation garantis.

Pour une PME, la bonne lecture est pédagogique. Silo est un banc d’apprentissage pour une personne capable de lire du C++, d’isoler un environnement et d’interpréter des mesures de concurrence. Il peut aider à comprendre pourquoi un débit plafonne ou pourquoi davantage de threads créent davantage d’attente. Il ne valide pas l’architecture d’un logiciel métier par simple ressemblance.

Comment s'en servir

Étape 1 : écrire l’hypothèse avant le test

Commencez par une phrase réfutable. Par exemple : « Le débit plafonne parce que plusieurs opérations se disputent les mêmes données » ou « Ajouter des travailleurs n’améliore plus le résultat au-delà d’un certain niveau de concurrence ».

Évitez les formulations vagues comme « la base est lente » ou « l’IA pourrait optimiser le système ». Elles ne définissent ni variable, ni résultat attendu, ni condition d’échec. Une hypothèse utile précise ce que vous modifiez, ce que vous mesurez et ce qui vous ferait changer d’avis.

Reliez ensuite cette hypothèse à un problème observé dans l’entreprise, sans prétendre reproduire immédiatement le système réel. L’objectif du laboratoire est d’apprendre un mécanisme. La décision métier viendra après, avec des mesures prises sur votre propre application.

Étape 2 : établir une référence simple

Choisissez une configuration de départ et consignez ses conditions : matériel utilisé, nombre de cœurs disponibles, volume de données, niveau de concurrence, type de charge et durée de l’essai. Gardez le même environnement entre les comparaisons.

Exécutez d’abord une charge stable, puis relevez au minimum le débit, le temps d’exécution et les erreurs éventuelles. Si vous ajoutez d’autres indicateurs, définissez-les avant le test. Une métrique choisie après avoir vu les résultats peut facilement devenir une justification.

La référence n’a pas besoin d’être spectaculaire. Elle doit être reproductible. Si deux exécutions identiques produisent des résultats très différents, cherchez d’abord la cause de cette variabilité avant de comparer des architectures.

Étape 3 : modifier une seule variable

Changez le nombre de threads, le profil de contention ou le volume de données, mais pas les trois ensemble. Relancez le même scénario et comparez le résultat à la référence.

Cette étape paraît lente. Elle évite pourtant le vrai gaspillage : conclure qu’une architecture fonctionne sans savoir quel changement a produit l’écart. Si le débit augmente puis plafonne, notez le point d’inflexion. S’il baisse lorsque la concurrence augmente, cherchez les ressources partagées et les attentes qu’elles provoquent.

Utilisez le mode de débogage et la vérification des invariants pour comprendre un comportement ou détecter une incohérence. Revenez ensuite au mode orienté performance pour les mesures de vitesse. Mélanger les deux reviendrait à comparer un moteur ouvert sur l’établi avec le même moteur lancé sur la route.

Étape 4 : comparer le mécanisme au système réel

Une fois le comportement compris dans Silo, revenez à votre application. Cherchez des signaux comparables : files d’attente, verrous, opérations concurrentes sur les mêmes enregistrements, saturation d’un cœur, temps passé dans une dépendance ou croissance du délai lorsque la charge augmente.

Ne transposez pas les chiffres du prototype. Transposez la méthode. Votre application possède son propre langage, son réseau, son stockage, ses données et ses règles métier. Le laboratoire vous apprend à poser une question plus précise, pas à prédire votre production.

Construisez alors un test limité sur votre système avec des données autorisées et un plan de retour clair. Gardez les mêmes entrées avant et après chaque modification. Si l’écart observé n’est pas reproductible, ne le transformez pas en promesse.

Étape 5 : décider avant d’ajouter l’IA

À ce stade, trois décisions deviennent possibles. Corriger le goulot identifié. Accepter la limite parce qu’elle n’affecte pas assez le métier. Ou lancer un nouveau test sur une autre hypothèse.

Une couche d’IA ne devrait entrer dans le scénario que si elle répond à une fonction définie : prévoir une charge, classer des demandes, assister une décision ou traiter une donnée non structurée. Mesurez alors son coût propre, sa latence, ses erreurs et le travail humain de contrôle. Sinon, vous risquez d’ajouter un appel variable et difficile à expliquer sur un chemin déjà lent.

Le livrable final tient sur quelques pages : hypothèse, protocole, résultats, limites, décision et prochain test éventuel. Pas un concours de graphiques. Une preuve exploitable.

Ce que ça coûte vraiment

Silo est publié sous licence MIT, mais le prix de téléchargement n’est pas le coût de l’expérience. Le premier poste est la compétence. Il faut une personne capable de travailler avec du C++, de comprendre l’exécution concurrente, de préparer un environnement isolé et de distinguer une anomalie du prototype d’un signal pertinent pour l’architecture étudiée.

Le deuxième poste est le temps de protocole. Définir une hypothèse, stabiliser une charge, répéter les essais et consigner les conditions demande plus d’effort qu’exécuter un benchmark une fois. C’est précisément ce travail qui donne une valeur au résultat. Sans lui, un chiffre de débit reste une capture sans contexte.

Le matériel compte aussi, mais il ne faut pas le surdimensionner trop tôt. Pour apprendre, un environnement multicœur dédié ou suffisamment isolé peut suffire. L’objectif initial n’est pas de reproduire le plus gros serveur imaginable. Il est de voir comment le comportement change lorsque la concurrence augmente. Si d’autres charges tournent en parallèle, elles doivent être contrôlées ou documentées, faute de quoi elles brouillent la comparaison.

Il faut ensuite budgéter la traduction vers le système réel. Un résultat obtenu avec Silo ne corrige aucune application métier. Quelqu’un devra instrumenter le service concerné, reproduire le problème, évaluer les changements possibles et vérifier leur effet. Cette phase peut conclure que le goulot n’a rien à voir avec le stockage transactionnel. Ce n’est pas un échec : c’est une hypothèse éliminée avant un investissement plus lourd.

Enfin, le coût d’une couche d’IA doit rester séparé. Ajoutez le prix d’usage ou d’hébergement, la latence, la supervision, la gestion des erreurs, la sécurité des données et la maintenance des consignes. Si l’IA améliore réellement le processus, ces coûts peuvent être justifiés. Si elle compense seulement une architecture non mesurée, elle devient une taxe ajoutée au problème.

Le budget honnête ne demande donc pas seulement « combien coûte l’outil ? ». Il demande combien coûte une décision fiable. Mesurer prend du temps. Corriger à l’aveugle en prend davantage.

Pour qui ce n'est pas

Silo ne convient pas à une PME qui cherche une base de données prête à exploiter, avec support actuel, mises à jour régulières et responsabilité contractuelle. Le dépôt se décrit comme un travail en cours et son dernier push remonte à 2017. Ces deux signaux suffisent pour écarter une recommandation de production.

Ce n’est pas non plus un bon premier exercice si personne ne maîtrise le C++ ou les bases de la concurrence. Dans ce cas, commencez par instrumenter l’application existante avec les outils déjà connus de l’équipe, ou faites encadrer l’atelier par une personne qualifiée. Un laboratoire mal compris produit surtout des conclusions confiantes.

Évitez aussi Silo si le problème observé concerne clairement une interface externe, un réseau instable, une tâche humaine en attente ou un traitement sans rapport avec des transactions concurrentes en mémoire. Un outil de recherche précis ne doit pas devenir un marteau universel.

Le projet est également inadapté si l’organisation veut prouver après coup qu’une architecture déjà choisie était la bonne. Un test utile doit pouvoir invalider l’hypothèse. Si seuls les résultats favorables seront retenus, le benchmark devient une décoration technique.

Enfin, ne l’utilisez pas comme détour pour repousser une décision simple. Si une requête évidente monopolise les ressources, si un service externe répond lentement ou si le processus attend une validation manuelle, commencez par ce fait observable. La sophistication du banc d’essai ne remplace pas la proximité avec le problème.

Silo s’adresse donc à une équipe qui veut apprendre à raisonner sur la performance, pas à une équipe qui veut ajouter une ligne prestigieuse à son architecture. Mesurer. Comparer. Décider. Puis seulement construire.

Source : https://github.com/stephentu/silo

FAQ

Silo peut-il être installé en production dans une PME ?

Ce n’est pas une recommandation raisonnable sur la base du dépôt. Le README parle d’un travail en cours et le dernier push remonte à 2017. Silo doit être traité comme un prototype de recherche et un support pédagogique, pas comme un produit maintenu avec garanties d’exploitation.

Que peut apprendre une PME avec Silo ?

Elle peut apprendre à formuler une hypothèse de performance, établir une référence, faire varier un seul paramètre et observer l’effet de la concurrence sur le débit. La valeur vient de la méthode de mesure, puis de sa transposition prudente au système réel.

Faut-il reproduire TPC-C pour obtenir un résultat utile ?

Non. La charge TPC-C multithread fournie par le projet aide à étudier un moteur transactionnel sous concurrence. Une PME peut s’en servir comme exercice, mais sa décision doit reposer sur un scénario représentatif de sa propre application et sur ses propres mesures.

Pourquoi mesurer avant d’ajouter une couche d’IA ?

Parce que l’IA ajoute ses propres coûts, délais, erreurs et besoins de supervision. Sans référence préalable, il devient difficile de savoir si elle améliore le système, déplace le goulot ou masque temporairement un défaut d’architecture.

Quels résultats faut-il conserver après le test ?

Conservez l’hypothèse, les conditions d’exécution, la variable modifiée, les mesures répétées, les écarts observés, les limites et la décision prise. Le résultat utile n’est pas le meilleur chiffre obtenu. C’est la capacité à expliquer pourquoi il change.

---

Publié le 23 octobre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.