Nous publions très régulièrement et depuis plusieurs années, dans les colonnes de ZeDen, des tests de matériel informatique, orienté gaming. Que ce soit des cartes graphiques, des alimentations ou même des cartes mères, nos articles suivent un protocole de tests, utilisant des outils. Qu'ils soient logiciels ou matériels, ils permettent de réaliser des mesures qui sont importantes pour comparer, analyser, et conclure sur tel ou tel produit de tel ou tel constructeur. Aujourd'hui, on va justement s’intéresser de plus près à l'un de ces outils qui nous affectionnons et qui fait partie intégrante de nombre de nos protocoles, à savoir l'outil OCCT. Adrien, son auteur, à bien voulu se prêter au jeu de l'interview pour ZeDen !

Peux-tu te présenter en quelques mots, ainsi qu'OCCT et son rôle ?

OCCT est un outil de test de stabilité matériel CPU/Mémoire, GPU, et alimentation, avec monitoring des tensions et températures en temps réel. Il est utile pour vérifier la bonne santé d'un ordinateur en termes matériel, pour vérifier la stabilité d'un overclocking, et diagnostiquer une panne.

Quant à moi, j'ai 30 ans, je suis un grand touche à tout [en] informatique (programmation, hardware, administration système, etc.), et je suis actuellement consultant dans le domaine de l'ECM (Electronic Content Management) et le BPM (Business Process Management).

Comment t'es venu l'idée de développer OCCT ?

Cela remonte à 2003. A l'époque, comme depuis plus de 10 ans maintenant, je trainais sur les forums hardware.fr, coté hardware, overclocking, et jeux vidéo. Petit à petit, je suis entré en contact avec « alanou », membre du staff hardware.fr, qui, entre autres, s'occupait de leur base de données d'overclocking. L'un des problèmes de cette base est qu'elle présente l'overclocking maximum atteint, même si il n'est stable que 3 minutes sous Windows. Si Windows boote, même peu de temps, c'est bon, tant que les screenshots sont là. Son idée était d'imposer le passage par un test pour introduire un certain degré de stabilité. J'ai mis le doigt dans l'engrenage, me suis lancé dans le code (j'apprenais la programmation en tant qu'étudiant à l'époque), et j'ai lancé l'outil, d'abord nommé HFR OC (très peu de temps, quelques mois), puis OCCT, ayant pris mon indépendance au cours du projet.

Es-tu tout seul à travailler sur ce projet ?

Oui, même si je reçois l'aide précieuse de tous les bêta-testeurs qui n'hésitent pas à rendre leurs machines instables pour vérifier qu'OCCT détecte bien les instabilités, et de « Fouge », auteur de CPUStressMT, avec qui nous avons défini un framework de plugins de monitoring.

Sur quels éléments techniques te bases-tu pour concevoir un benchmark ?

OCCT n'est pas un benchmark dans le sens où il va classer les machines face à un score donné. C'est le travail de 3DMark, des rundemos, et autres outils similaires, et je n'ai pas trop envie de me diriger dans ce domaine. Le seul but d'OCCT est de détecter les erreurs de stabilité, de voir si, matériellement, le PC tient la route.

L'idée de base derrière OCCT est de charger la machine au maximum, et de la pousser dans ses derniers retranchements. Cela créé un terrain très favorable à ce qu'une erreur arrive. Il faut bien comprendre que si un CPU est instable, il va générer des erreurs de calcul, par exemple 2+2=5. Ces erreurs sont par essence aléatoires : on va avoir le bon résultat, jusqu'à ce que le composant fautif fasse une erreur.

Et le meilleur moyen de détecter une faiblesse, c'est de charger un maximum la machine. Je vais faire fonctionner la machine à pleine puissance, pour que si erreur il y a, elle soit détectée le plus vite possible. Il ne faut pas oublier le coté aléatoire : autant si je détecte une erreur, le diagnostic est définitif (composant instable, on en est sûr), autant ne pas détecter d'erreurs ne signifie pas [que] le composant est stable. L'erreur ne s'est peut-être tout simplement pas produite. Cela donne des débats sur la durée minimale d'un test, certains allants jusqu'à 48h...

Est-ce que tu as tout développé « from scratch », ou bien as-tu utilisé des bibliothèques déjà existantes ou projets open source ?

CPU:OCCT s'inspire de Prime95, CPU:LINPACK est l'intégration d'un test d'origine Intel, un peu bidouillé par des gens du forum overclockers.ru pour le rendre compatible avec AMD (Intel a implémenté un test empêchant ce programme de s'exécuter sur CPU AMD). GPU:3D est une création totalement maison, en DirectX9 et 10, et s'inspire très librement d'algorithmes originaires de Pixar. GPU:Memtest, qui va revenir bientôt, est aussi une création maison, qui reprend le fonctionnement général de memtest86, porté sur la mémoire des cartes graphiques.

Quel est le langage de programmation utilisé, et pourquoi ce choix ?

Le but était d'être à la fois efficace, et de marcher sur le plus de machines possibles, sans dépendances trop fortes. Il serait difficile de forcer quelqu'un à installer une machine virtuelle, comme Java par exemple, sur chaque PC qu'il veut tester dans son environnement. Je veux vraiment être un .exe sur clé USB, on lance, et ça tourne d'entrée, sous Windows. L'interface utilisateur a longtemps été codée en Delphi, donc sans aucune dépendance, mais j'ai récemment changé pour du C# .NET 2.0, étant donné que ce framework est présent sur tout système d'exploitation Vista et Seven « out of the box » [NDLR : nativement], et sur énormément de postes XP. Les tests sont faits en C++, aussi pour avoir le minimum de dépendances tout en gardant une grande efficacité au niveau du code. Les tests 3d sont basés sur du DirectX, pour une raison plus d'efficacité que de compatibilité : selon mes tests, le même algorithme en OpenGL était en retrait de 20% face à la version DirectX. Pour moi, cette différence est à imputer au niveau de l'optimisation des pilotes graphiques, la plupart des jeux étant en DirectX, il draine le maximum d'attention, ce qui est, en soi, logique.

La version 4.2 a introduit de nouvelles versions. C'est un grand changement, ces versions étant payantes. Peux-tu expliquer les motivations de ce choix ?

Contrairement à une idée reçue, OCCT n'a jamais été « gratuit » en usage professionnel. La licence spécifiait bien ce point. Je savais pertinemment qu'il était utilisé au niveau professionnel, mais n'ayant pas d'alternative payante ou autorisée dans un tel milieu, je n'allais pas empêcher les gens de l'utiliser. J'ai ensuite lancé les versions pro et live, après avoir reçu pas mal d'emails me demandant des fonctions qui ne seraient, selon moi, utiles qu'en environnement professionnel. Prenons un SAV d'une boutique. Ce qu'ils veulent, c'est vérifier si matériellement le PC est stable, en un minimum de temps et d'efforts. Si le technicien doit lancer l'OS du client, avoir Adibou lancé au démarrage, copier OCCT via une clé USB qui risque de se faire contaminer par les virus du client, et lancer le test manuellement, c'est à la fois inefficace et une perte de temps. D'où la naissance d'OCCT Live, permettant au technicien de booter sur la clé USB, et de revenir une fois que le test pré-programmé serait terminé : tout s'est déroulé automatiquement, et de plus, dans un environnement sain et sans virus aucun.

L'idée est maintenant de me tourner vers le monde professionnel, de leur fournir un outil adapté à leurs besoins, avec un support dédié. Cela me permettra de dégager des fonds, qui seront principalement investis dans le développement d'OCCT et dans l'achat du matériel de test, et peut-être, à long terme, de pouvoir me consacrer à plein temps à OCCT. Mais là, on en est encore très, très, loin !

La version gratuite va-t-elle perdurer ?

Ad vitam aeternam. C'est ma priorité. C'est cette version qui a fait d'OCCT ce qu'il est actuellement, et cela restera toujours une priorité. Je n'ai pas envie d'en faire une version « castrée », de priver les gens de fonctions qui leurs seront utiles. Autant je doute qu'un utilisateur ait besoin d'une clé USB bootable pour tester sa machine (cela ne se justifie que si tu en testes un grand nombre), autant le test de mémoire GPU est, lui, très intéressant pour tout le monde. Quand je l'aurai recodé, il sera disponible dans toutes les versions.

Aucune fonction qui a été disponible gratuitement par le passé ne deviendra payante. J'inclus dans les versions payantes un panel de nouvelles fonctions dédiées aux professionnels, tout simplement.

Les constructeurs/revendeurs t'aident-ils dans ta démarche de développement ?

J'ai reçu beaucoup de soutien de LDLC et de Materiel.net, qui m'ont aidé à obtenir du matériel de prêt pour résoudre des problématiques très pointues liées au matériel. Historiquement, Nvidia m'a souvent écouté et envoyé du matériel de test. Gigabyte, Asus et Intel m'ont aussi envoyé du matériel de test ponctuellement. Les relations avec AMD ont été plus difficiles, il m'a fallu passer par la case « grand clash » avec le problème de conception des Radeon HD4xxx pour avoir une oreille attentive. Il va de soi que je les remercie tous chaleureusement ! En termes de volume, j'ai eu en tout 6 cartes graphiques (ce qui est un peu le nerf de la guerre), 1 CPU, et une carte mère.

benchmarks existants, quel est celui que tu apprécies le plus, à part OCCT, et pour quelles raisons ?

J'aurai toujours un petit faible pour CPUStressMT coté CPU. Il est né lors d'une période creuse du développement d'OCCT, où j'étais pris par le début de ma carrière professionnelle. « Fouge », son auteur, a voulu reprendre le flambeau. C'est quelqu'un que j'estime beaucoup, qui a fait de grandes choses sur ce petit programme, et je regrette qu'il soit à l'heure actuelle, en dormance. Le fait qu'il soit issu d'un bêta-testeur assidu d'OCCT, développé et suivi sur le même forum joue beaucoup.

J'ai aussi beaucoup d'estime pour « JegX » et Furmark. « JegX » est bien plus pointu que moi en 3D, cela se voit en lisant son site. J'ai appris la 3D sur le tas, c'est son métier, la différence se situe là. Nous avons néanmoins deux approches différentes : je propose un test simple et, du coup, très efficace, « JegX » propose un test bien plus abouti et enrichi en fonctionnalités, ce qui lui coûte un peu en termes d'efficacité à mon avis. Néanmoins, les deux approches sont complètement valides, nous sommes partis de la même base autour de l'algorithme 3D, et là où « JegX » remporte haut la main la palme des fonctionnalités, je remporte la palme de l'efficacité comme l'a montré récemment un graphe officiel AMD lors du lancement d'une de ses gammes.

Y a-t-il, à ton sens, encore de la place sur le « marché » des benchmarks ?

Il y en aura toujours. C'est d'ailleurs une place où les outils vont et viennent rapidement. Il y a aussi beaucoup d'effet de « mode ». Par exemple, aux USA, tout a commencé avec CPUBurn, suivi de Prime95, suivi de IntelBurnTest, suivi de LinX, le tout sur effet de mode et de popularité, et OCCT durant tout ce temps. Ce n'est que du bouche-à-oreilles. J'ai vu beaucoup de concurrents aller et venir. Je suis le seul à être là depuis 2003, et à proposer une gamme complète de tests (CPU, GPU, Alim) et le monitoring en temps réel. J'attends toujours de nouveaux concurrents, cela me donne souvent un grand nombre d'idées.

As-tu une idée du nombre de téléchargements d'OCCT, toutes versions confondues, depuis son lancement ?

Entre 9 et 10 millions, juste sur le site officiel. Difficile de dire avec tous les miroirs, par contre !

Quel est le secret de cette longévité ?

Être à l'écoute du retour des gens, suivre leurs idées (mais pas toutes ;) ), faire évoluer son outil, ne pas lâcher l'affaire, et des fois, faire la une, comme avec l'histoire des Radeon HD4xxx. Je crois aussi que le tout est de toujours trouver du plaisir à développer l'outil. J'ai rarement aimé coder un programme comme je code OCCT, où je fais ce dont j'ai envie, au moment où j'en ai envie. Quand je me suis lancé dans la programmation de GPU:3D, j'ai appris une tonne de choses, je ne connaissais absolument pas le domaine. J'ai avancé petit à petit, défrichant le sujet que je juge très complexe, et je crois que c'est finalement ce qui me fait le plus avancer : apprendre et m'amuser en codant.

Quelles sont les prochaines features que tu souhaites embarquer dans l'outil ?

La version 4.2.1 sera compatible Windows 8, et proposera un graphe de toutes les tensions détectées. Je compte bien faire renaître GPU:Memtest et le recoder entièrement (en abandonnant CUDA au passage), ainsi que faire en sorte qu'OCCT Live puisse lancer plusieurs tests, les uns après les autres.

Quelles sont les limites actuelles d'OCCT ?

La plus grosse limite d'OCCT : son coté aléatoire. Je ne fais que créer un terrain propice à ce qu'une erreur arrive. On peut très bien avoir sur un test une erreur en 5 minutes, et le lancement suivant, une erreur seulement au bout de 45 minutes, ou au bout de 2 heures. Je reste tributaire du hasard et de la chance... Cela conduit au scepticisme de nombre d'utilisateurs. Quand OCCT détecte une erreur sur un PC aux fréquences d'origines, souvent, on voit un message mentionnant « bug d'OCCT ? ». OCCT a eu sa part de bugs, mais seule une version stable (datant de 2006 de mémoire) a pu rapporter d'erreurs là où il n'y en avait pas. Il faut donc faire confiance au logiciel, or, on a tendance à faire confiance à soi-même, au PC qu'on vient de monter et de configurer. Souvent, si on donne des conseils de base pour vérifier le matériel : timings mémoire, augmenter le refroidissement, augmenter un peu les tensions, ... ça va mieux. Et donc, le bug d'OCCT est écarté.

Le problème, c'est que Google indexe « bug occt » à chaque coup ! Bon, la réputation est là, mais ça m'ennuie toujours un peu.

As-tu un message pour les lecteurs de Zeden.net, ou autre chose à ajouter ?

J'aime beaucoup ZeDen que j'ai découvert récemment, et j'ai envie de dire à ses lecteurs : utilisez OCCT ! Oui, je sais, je fais original !