Aller au contenu principal
Trouver ma solution
Langue : Français

Comment nous testons

Cette page explique comment George teste les services que nous comparons : comment les comptes de test sont ouverts, ce que nous notons et les limites de chaque résultat.

Dernière mise à jour :

Ce que nous testons

Nous testons ce que vous feriez vous-même après avoir loué un service : le configurer, lui confier un vrai travail, le mesurer et noter ce qui ne va pas. Chaque résultat indique la date, le fournisseur, la formule et les versions avec lesquelles il a été mesuré.

Nous ne décrivons jamais un test qui n'a pas eu lieu. Quand une page avance un fait que nous n'avons pas mesuré, elle cite la source, par exemple la page de tarifs du fournisseur lui-même, et la date à laquelle nous l'avons lue.

Comment nous ouvrons les comptes de test

George ouvre lui-même chaque compte de test, comme un client ordinaire, directement sur le site du fournisseur. Il ne s'inscrit jamais via les boutons Visiter ni via un autre lien de notre site.

Ce que nous notons

Pour chaque test, nous tenons un journal avec :

  • la date et l'heure de chaque exécution
  • le fournisseur, la formule et la région du centre de données
  • le système d'exploitation et la version de chaque application et de chaque modèle
  • les réglages que nous avons modifiés
  • les commandes que nous avons lancées et leur sortie brute

Un article n'affiche un encadré « Comment nous avons testé » que lorsqu'un tel journal existe.

Tant qu'un banc d'essai n'a pas tourné, un article s'appuie sur des données publiées et cite chaque source avec sa date.

Comment nous mesurons la vitesse et la mémoire

Une seule exécution peut avoir de la chance ou non, c'est pourquoi chaque vitesse que nous publions est la médiane d'au moins 3 exécutions : la valeur du milieu quand les résultats sont classés. Nous enregistrons l'utilisation de la mémoire et du processeur pendant tout le test, au lieu de la relever une seule fois.

Les limites de chaque résultat

Chaque résultat indique ses limites, en général une région, une semaine et une version de chaque application ou modèle. Un fournisseur peut changer son matériel, ses prix ou ses logiciels après notre test : chaque résultat porte donc sa date.

Nous relançons chaque banc d'essai une fois par an, et plus tôt si une nouvelle version ou une formule modifiée peut changer le résultat.

Captures d'écran

Nos captures d'écran proviennent uniquement des propres comptes de George. Avant d'en publier une, nous la recadrons sur l'essentiel et retirons les données personnelles, adresses IP, clés et adresses e-mail.

Qui réalise les tests

George réalise chaque test. Il ouvre les comptes, démarre et arrête les serveurs, lance les scripts de test et conserve la sortie brute. Pour en savoir plus sur lui, consultez la page À propos.

Comment nous utilisons les outils d'IA

Les outils d'IA nous aident pour la recherche, la rédaction et la vérification des faits. George réalise chaque test et valide chaque article avant sa publication.

Nos bancs d'essai

Un banc d'essai est un ensemble de serveurs ou de services loués et les tests que nous y lançons. Plusieurs articles partagent chaque banc, et chaque encadré « Comment nous avons testé » renvoie au banc utilisé.

T1 Banc d'essai des agents

Prévu : les résultats apparaîtront ici avec leur date.

Nous louons des serveurs et des formules gérées pour agents IA, chacun pour un mois. Chaque serveur fait tourner n8n, OpenClaw et Hermes Agent avec les mêmes cinq workflows et trois tâches d'agent.

Nous enregistrons l'utilisation de la mémoire et du processeur toutes les 5 minutes pendant 7 jours et vérifions que les webhooks arrivent. Nous scannons aussi nos propres serveurs depuis l'extérieur à la recherche de ports ouverts, puis testons une mise à jour, un retour en arrière et une restauration depuis une sauvegarde.

T2 Banc d'essai des modèles sur CPU

Prévu : les résultats apparaîtront ici avec leur date.

Nous faisons tourner de petits modèles ouverts sur le processeur, sans GPU. Des serveurs avec 8, 16 et 32 Go de mémoire font tourner Ollama avec quatre petits modèles, chacun avec deux niveaux de quantification. Nous mesurons les tokens par seconde et l'utilisation de la mémoire.

T3 Banc d'essai GPU

Prévu : les résultats apparaîtront ici avec leur date.

Nous louons des GPU de 24, 48 et 80 Go de mémoire et lançons le même script de benchmark sur chacun. Il fait tourner des modèles de trois tailles (8B, de 27B à 32B, et 70B ou gpt-oss-120b) sur deux moteurs : llama.cpp (ou Ollama) et vLLM.

Nous testons chaque modèle avec un utilisateur, puis avec huit utilisateurs en même temps, et répétons chaque exécution trois fois.

T4 Banc d'essai du fine-tuning

Prévu : les résultats apparaîtront ici avec leur date.

Nous réalisons un fine-tuning LoRA et QLoRA avec Unsloth sur des modèles de 8B, de 27B à 32B et de 70B, tous avec le même jeu de données. Nous comparons ensuite les réponses à 20 prompts de test avant et après l'entraînement.

T5 Banc d'essai des chatbots

Prévu : les résultats apparaîtront ici avec leur date.

Nous donnons à plusieurs services de chatbot documentaire les mêmes 30 documents et les mêmes 40 questions, afin de pouvoir comparer leurs réponses côte à côte.

T6 Banc d'essai image et vidéo

Prévu : les résultats apparaîtront ici avec leur date.

Un workflow ComfyUI fixe crée 100 images et quelques courts clips. Il tourne sur un GPU loué et sur deux services ComfyUI utilisables dans le navigateur, dont l'un est facturé à l'heure.

Deux modèles vidéo tournent sur deux types de GPU, et nous chronométrons un entraînement LoRA de Flux. Nous enregistrons le pic de mémoire GPU de chaque tâche.

T7 Serveur GPU au mois

Prévu : les résultats apparaîtront ici avec leur date.

Nous louons un serveur GPU au mois et chronométrons le temps nécessaire pour que la commande soit prête. Nous lançons ensuite le même script de benchmark que sur le banc T3.

T8 Maîtrise des dépenses

Prévu : les résultats apparaîtront ici avec leur date.

Sur les comptes ouverts pour les bancs T1 et T3, nous configurons la limite de dépenses, l'alerte ou le solde prépayé de chaque fournisseur. Nous vérifions ensuite si les dépenses s'arrêtent vraiment en atteignant une petite limite.