Projets

Criteo prédit l'avenir avec une obligation de performance

Retrouvez cet article dans le CIO FOCUS n°125 !

Qualité du Système d'Information : développements, infrastructures et niveaux de service

Si le système d'information s'arrête, l'entreprise ou l'administration s'arrête. C'est évidemment inacceptable. De la même façon, un dysfonctionnement informatique implique un dysfonctionnement métier et un service mal rendu au client ou à l'utilisateur. C'est tout autant préjudiciable. La qualité...

Découvrir

---

A l'occasion de la Matinée Stratégique CIO « Qualité SI » le 27 septembre 2016 à Paris, Nicolas Helleringer, directeur engineering de Criteo, a apporté son expérience de la qualité et de la performance du système d'information.

PublicitéSuivie sur CIO depuis des années, Criteo n'est pas n'importe quelle entreprise française. Du statut de start-up, elle est passée à celui de licorne et, qui plus est, de belle licorne avec une valorisation qui est aujourd'hui dans les environs de deux milliards d'euros. L'un de ses co-fondateurs, Jean-Baptiste Rudelle, en a raconté l'histoire. Au sein de cette société, la performance du système d'information est un impératif, au même titre que les très nombreuses et régulières mises à jour de son outil.

Cela implique une démarche que Nicolas Helleringer, directeur engineering de Criteo, a présenté lors de la Matinée Stratégique CIO « Qualité SI » le 27 septembre 2016 à Paris.

« Criteo prédit l'avenir mais dans un domaine bien précis -ce qui fait que nous réussissons- à savoir les probabilités d'achats en lien avec les comportements antérieurs des internautes » a expliqué Nicolas Helleringer. Il complète : « notre travail est d'afficher la bonne publicité auprès de la bonne personne au bon moment. » Pour cela, Criteo trace l'activité des internautes en ligne de façon anonyme. En fonction de telle ou telle action en ligne, sans lien avec une identité, les algorithmes de Criteo vont déduire que l'internaute va probablement désirer telle chose.

« Nous savons ce que font les gens, pas qui ils sont, pour dire qu'ils ont plus de chance d'être intéressé par tel type de produit, de service, etc. » a insisté Nicolas Helleringer. Il y a ainsi 16 millions de variables traités pour chaque individu ! Toute intervention humaine pour qualifier des groupes a priori a toujours dégradé les performances.

La performance extrême est impérative

Bien entendu, il ne peut pas être question qu'un internaute attente dix minutes l'affichage d'une publicité sur le site qu'il consulte. Or l'affichage d'une publicité implique d'une part l'analyse de la « demande » de l'internaute (de son profil) mais aussi de l'offre publicitaire puisque les annonceurs procèdent par enchères sur les profils. « Dans le cas d'enchères sur des espaces publicitaires sur un site média, lorsqu'un internaute va arriver, le média va interroger un certain nombre de réseaux de diffusion de publicités, dont nous faisons partie, et nous avons 100 ms au maximum pour répondre et avoir choisi quelle publicité afficher à cet internaute, en précisant quel montant nous sommes prêts à investir pour afficher une publicité à celui-ci, à ce moment là, sur ce site » détaille Nicolas Helleringer. Or, si Criteo paye à l'affichage, de l'autre côté, il n'est rémunéré qu'au clic. Il lui faut donc être performant pour définir quel internaute a quelle probabilité de cliquer sur une publicité.
Criteo doit donc traiter de très nombreuses informations. Chaque service algorithmique répond en quelques millisecondes, ce qui permet au global à l'entreprise d'être très performante dans sa rapidité de réponse, de l'ordre de 4,5 ms. Si c'est plus lent que le trading haute fréquence (où l'unité est la nanoseconde), la quantité de données traitée est bien supérieure : des centaines de pétaoctets de données. Chaque jour, 150 milliards de requêtes sont traitées sur les sept datacenters dispersés dans le monde. Les marges sont autant microscopiques que les temps de réponse : il faut donc multiplier les opérations pour gagner de l'argent. Et la pression sur les infrastructures est donc colossale. Nicolas Helleringer a admis : « notre manière de faire de l'informatique est très particulière. » En particulier, il est indispensable de baisser les temps de latence, ce qui implique de disposer d'une informatique totalement internalisée et contrôlée de bout en bout.

PublicitéS'adapter aux évolutions régulières des algorithmes

A ces contraintes sur le run s'ajoutent des contraintes sur le build. « Le nerf de la guerre, c'est l'algorithme » a avoué Nicolas Helleringer. Les différents algorithmes changent en moyenne toutes les semaines avec environ 300 patches et reviews par jour ainsi que 1400 releases par trimestres. Or la qualité du code produit ne doit pas remettre en cause la qualité et les performances de l'exécution.
S'il n'y a pas de mystère pour y arriver, il y a beaucoup de bonnes pratiques, de méthodes et de rigueur, bien au delà du seul DevOps. Pour commencer, Nicolas Helleringer a mentionné : « j'ai parlé de review car aucune ligne de code ne sort sans qu'elle n'ait été revue par une personne, le plus souvent deux. » Les développeurs ont des retours très rapides sur leur travail. Dès qu'un code est envoyé dans le dispositif de validation, il y a un premier retour dans les 7 à 8 minutes qui suivent sur l'interopérabilité avec le reste du code. « On contrôle les 24 millions de lignes de code de Criteo en permanence pour tous les développeurs » a observé Nicolas Helleringer. Cette phase est bien sûr totalement automatisée. Si la portion de code réussie cette étape, on passe à la revue manuelle puis aux processus de tests (unitaires, d'intégration, etc.).

L'humain et l'automatisation s'associent

La relecture du code est nécessairement manuelle. C'est bien un humain qui va relire le code et contrôler sa lisibilité. Même s'il existe des outils pour contrôler la qualité du code dans les langages employés (C#, Java, Javascript, Python...), rien ne remplace encore aujourd'hui une relecture humaine. C'est celle-ci qui apportera le plus de valeur. Et nul n'échappe à la règle. Même Nicolas Helleringer voit son code contrôlé de la sorte par des pairs parfois d'un niveau inférieur au sien avec, de temps à autre, l'obligation d'expliquer l'intention derrière le code. Et, ça, ce n'est pas bon.
« Devoir commenter le code signifie que l'on a échoué à rendre son code lisible, même s'il devra bien sûr être documenté par ailleurs » a en effet jugé Nicolas Helleringer. Avoir un code lisible, c'est par exemple une écriture correcte qui met les opérations dans l'ordre logique, en respectant les derniers axiomes de chaque langage. Pour Nicolas Helleringer, « un code doit être efficace, il doit être performant mais il ne faut pas oublier qu'il doit aussi être lisible car si le code est écrit une fois, il sera relu cinquante fois derrière. » Si le code n'est pas clair, cela fera perdre beaucoup de temps ensuite. Et cela se joue parfois sur des détails comme le nom des variables.

Intégration en douceur

Une fois que le code a passé toutes ces étapes de validation, on arrive à l'étape de l'intégration. Le code est ici testé sur une plate-forme où va être joué un peu de trafic. La validation en production sera, ensuite progressive. « Une fonctionnalité tourne actuellement sur 500 serveurs à New York mais, lorsque l'on déploie une nouvelle version, on va commencer par 2 serveurs » a décrit Nicolas Helleringer. Simplement parce qu'il est quasiment impossible de simuler totalement les 150 milliards de requêtes par jour avec toute la diversité dans ces requêtes. Une telle mise en production progressive est donc absolument obligatoire avec des tests à six, douze et vingt-quatre heures.
Pour l'intégration des nouvelles versions de code, Google a opté très tôt pour stratégie simple : tout recompiler à chaque mise à jour. Ce n'était pas le choix de Criteo jusqu'en 2013. Mais les évolutions en parallèle de modules, y compris de modules centraux, posaient des problèmes d'intégration. Criteo a donc aussi opté pour la recompilation globale systématique. Nicolas Helleringer s'est souvenu : « cela nous a pris un trimestre pour nous remettre d'équerre avec beaucoup plus de tests automatiques. » Du coup, il est devenu très rapide de constater qu'un problème d'interface est survenu, sans qu'il soit nécessaire d'attendre la mise en production.
Et s'il y avait une seule bonne pratique à retenir, Nicolas Helleringer n'a pas hésité une seule seconde : « investir dans son usine logiciel. Il faut de bons outils pour employer au maximum de ses capacités la seule ressource vraiment rare en informatique, à savoir l'humain. » Une équipe dédiée de 6 personnes est entièrement consacrée à temps plein à l'usine logicielle.

Article rédigé par

Bertrand Lemaire, Rédacteur en chef de CIO

Partager cet article