devops chez Antidot

DevOps, kesako ?

Le terme DevOps est apparu il y’a environ une dizaine d’années et est largement utilisé dans de nombreuses fiches de poste (dont la mienne) mais il reste encore flou aujourd’hui. Je vais donc essayer de me lancer dans une définition ; ou du moins dans la définition que nous en faisons chez Antidot.

Origine du mot DevOps

nuage de mot devopsDevOps vient de la contraction de 2 termes anglais « development » « operation* ( *exploitation en français) ». Cela part du postulat qu’il y’a donc deux mondes, celui des développeurs donnant vie à un produit, et celui des administrateurs système qui l’opère dans le Datacenter.

Avec l’apparition des méthodes agiles, ce postulat est mis à mal, et le terme DevOps fait son apparition en proposant le trait d’union entre ces deux mondes. Le « DevOps engineer » n’est plus un simple admin, mais s’oriente plus vers un développeur qui aurait pleinement conscience des ressources requises par son produit, et saurait comment l’opérer efficacement dans un espace de production car il en connaît toutes les ficelles. Cette double compétence permet une grande réactivité, et est un atout non négligeable dans un procès de déploiement continu ou d’intégration continue.

Et Antidot alors ?

Antidot est un éditeur logiciel spécialisé dans la transformation et l’enrichissement de données, aussi, la société propose plusieurs produits qui utilisent une architecture assez complexe. C’est là qu’une approche DevOps est intéressante, voir indispensable pour opérer un Datacenter en perpétuelle évolution.

En effet, le marché fait que nous avons régulièrement besoin d’ajouter/réinstaller de nombreuses machines. Amazon avec AWS fait ça très bien, mais nous préférons opérer nous-même 95% de notre Datacenter (5% étant quand même chez AWS). Nous voulons avoir la même souplesse qu’AWS en termes de mise à disposition de machines, pour cela nous utilisons divers outils qui nécessitent des compétences en développement comme Puppet (ruby)/Ansible (python)/FAI (bash) ou encore Docker et LXC pour la virtualisation. Aujourd’hui une installation complète d’une machine pour notre DC (comprendre avec compte UNIX, produit installé « Up & Running ») prend moins de 10 mins pour une machine bare-métal, moins de 5 minutes pour un container LXC et quelques secondes pour un container sous docker.

Même si cette partie utilise des compétences de DEV, elle reste très orientée, OPS. Ce n’est pas le seul besoin que nous avons chez Antidot, comme je l’évoquais un peu plus haut, nous avons besoin de réduire et d’automatiser au maximum le passage en production de chaque ligne de code* (*de chaque commit)  produite par nos développeurs « de souche ». Il a fallu repenser toute la chaine de livraison/test de notre solution.

devops chez Antidot

Ce besoin est résolu avec la mise en place d’une architecture basée sur les fonctionnalités offertes par docker et gitlabCI. Ainsi, un développeur peut à loisir développer dans une branche git sur son propre poste, chaque commit déclenche l’instanciation d’un environnement virtualisé complet à l’image de notre production, afin d’y effectuer une série de tests. Une fois tous les tests passés, le commit est automatiquement mergé/fusionné dans la branche principale de notre produit, et une nouvelle version est livrée, prête à être installé en production. A chaque étape, une notification est envoyée au développeur (dans une room Hipchat) lui permettant un retour « temps réel ». Il va de soi que le déploiement vers l’environnement de production est également automatisé, ce qui ne veut pas dire automatique. Nous préférons garder le contrôle sur le moment où nous déployons en un clic vers tout notre parc de production. A titre d’exemple, avant cette automatisation, une mise à jour de production pouvait prendre plus d’une journée à un de nos administrateur système pour tout le parc, elle a été réduite à 20 secondes pour appeler la commande et à 20/30 minutes pour son exécution (temps incompressible d’arrêt et de redémarrage des services sur tout notre parc de production).

Le monitoring en Devops

Le monitoring est egalement opéré en mode DevOps. Chez Antidot, nous utilisons principalement Shinken. Shinken utlise une liste de « hosts » et de « probes » statique. Avec notre Datacenter devenu dynamique, il a fallut ecrire une bibliotheque capable de découvrir tous les hosts provenant de notre inventaire (GLPI) et de leur appliquer les bonnes sondes metier en fonction de certain critères/tags. Grace a cette bibliotheque écrite en Python, nous pouvons par exemple ajouter une machine dans un cluster Mongo (Kickstart + playbook Ansible), le monitoring arrive automatiquement avec uniquement les  psondes necessaire.

schema devops

Le « devops » chez Antidot ne consiste pas à réinventer la roue, mais à utiliser une multitude d’outils/de standard open source (ou non), et de créer le « liant » entre tous ces outils afin de ne pas avoir à répéter deux fois une même action (là ce sont mes origines Corses qui parlent). D’aucun diront* (* les mauvaises langues) que c’est une sorte de fainéantise poussé à l’extrême, afin de simplifier ses tâches. Je préfère dire que c’est plus une façon de se débarrasser des tâches ingrates/répétitives en créant une architecture « vivante » et « dynamique », et surtout plus intéressante, piloté d’une main de maitre 🙂

C’est un défi que nous aimons relever et qui nous permet de nous tenir au fait des nouvelles technologies. A ce titre, si tu es comme nous et que tu souhaites faire de cette philosophie devops ton quotidien, je rappelle qu’Antidot recrute un Administrateur DevOps, n’hésite pas à nous contacter, toute proposition sera étudiée.

Article rédigé par Yann Finidori

matinee hub retail

Matinée au Hub Retail à Lyon le 25/01

Le Hub Retail est une association professionnelle rhône-alpine qui fédère des commerçants et acteurs du secteur concernés par le cross canal et les questions connexes. De même qu’en septembre dernier Equip Mag (salon spécialisé pour le retail physique, point de vente) et eCommerce Paris étaient regroupés, pour hub retail, il n’y a plus de ecommerce, uniquement du commerce.

Notre client King Jouet en est membre fondateur d’Hub Retail et m’a proposé d’y assister.

Hub Retail organise tous les mois des matinées d’échange. Ce 25 janvier la rencontre a eu lieu à Lyon.

Le coeur de la matinée était un retour de visite au NRF à New-York d’Olivier Dauvers, journaliste spécialisé brillant qui n’a pas sa langue dans sa poche.

Il a parlé de 4 innovations qui l’ont marqué par leur intelligence, non pas technique mais « marketing » de solution à une problématique de la relation client.

– utilisation de capteurs (type accéléromètres / volume du pied) pour caractériser finement l’adéquation d’une chaussure de running avec la morphologie/foulée du client. Le commerçant en tire une information d’une grande valeur qui pousse le client à s’approprier le produit plus facilement.

– application de yield management à des denrées périssables. L’exemple montré était basé sur un rayon boulangerie équipé d’étiquettes pilotables à distance. L’historique de vente analysé permet de prévoir finement l’impact du prix sur les ventes, et donc de réduire la perte pour des produits à durée de vie courte.

– utilisation de reconnaissance d’image pour détecter les rayon vides à partir de caméras montées sur l’ensemble des caddies du magasin : ces caméras grand angle parcourent sans cesse les rayons, transmettent en temps réel les images captées et permettent de voir dans quel linéaire on a des manques. La détection se fait en quelques secondes, sans besoin de parcourir physiquement le magasin. Le réassort peut ainsi se faire très rapidement.

– Utilisation de reconnaissance d’image pour compter le contenu du caddie sans besoin de RFID sur chaque produit. Une caméra est placée sur la poignée du chariot. Elle filme en continu le caddie et détecte les produits qui y sont posés (ou enlevés) afin de permettre un paiement sans caisse et sans attente. L’intérêt de ce système réside dans l’absence de puce RFID sur chaque produit.

L’intervention se termine sur la présentation de la librairie physique Amazon ouverte à Seatlle. C’est un très bon exemple d’application du meilleur du online sur un produit off line. On trouve dans cette librairie :

– quelques milliers de titres mais uniquement les meilleures ventes (les autres sont dispos en ligne)

– tous les livres sont montrés de face vs sur la tranche dans une librairie traditionnelle (torticoli garanti)

– les livres sont classés par thématique et ont tous un extrait des avis clients et les étoiles des internautes. Chaque livre est ainsi bien mis en valeur.

– au delà des thématiques, de nombreuses « aspérités » dans la présentation de l’offre sont présentes : les 100 livres qu’il faut avoir lu dans sa vie, si vous avez aimé tel livre, vous aimerez  celui là ou celui là, parmi les policiers, une sélection d’histoires vraies, … 

– et bien sûr captation de toute information via un compte client unique partagé Amazon bookshop et Amazon online.

La matinée se poursuit par une table ronde retour d’expérience sur la politique omni canal basée sur l’expérience de King Jouet d’un côté, et de la Boite à Outil de l’autre. 

Cette table ronde est également animée par Olivier Dauvers qui n’hésite jamais à challenger les visions des différents intervenants, quitte à pointer des contradictions ou des situations difficiles. 

Dans les deux cas des histoires différentes, des contextes concurrentiels différents, et des approches disctinctes sur l’apport du cross canal.

La politique de prix et d’offre entre site internet et magasin physique par exemple est traitée différemment par les deux marchands.

Enfin, la matinée se termine par un cocktail networking qui est l’occasion de rencontrer les fondateurs d’Improveeze, l’inventeur français du concept de « phygital » dans le retail, alliance du monde physique et du monde digital en magasin.

Une excellente matinée donc, tous le remerciements à Olivier Bourgeois, fondateur et délégué général du Hub Retail

La culture de l’innovation chez Antidot : les conférences

Un éditeur de logiciels innovants se doit d’entretenir une culture de l’innovation au sein de ses équipes. Chez Antidot, nous utilisons plusieurs outils pour cela : les Brown Bags, les Ship It, le développement de prototypes, la publication de logiciels en Open Source

Il est important de compléter cette palette en ajoutant de l’entropie – être ouvert à d’autres idées, à des méthodes de travail alternatives – et en veillant à rester informé des dernières évolutions des techniques, langages et frameworks que nous utilisons. Pour cela nos développeurs participent à des évènements, grands ou petits, locaux ou internationaux, tout au long de l’année.

L’objectif de ce billet est de vous présenter les nombreux évènements auxquels nous avons participé en 2015. Chacune de ces manifestations est illustrée par le témoignage d’un développeur qui y a participé :

FOSDEM – 31 janvier et 1er février 2015, Bruxelles

Aurélien : « J’ai eu l’occasion d’assister au FOSDEM à Bruxelles en 2012/2013/2014/2015.Un moment formidable pour rencontrer et échanger avec la communauté open source et les représentants de ses projets les plus populaires : Linux, Firefox, Gnome, KDE, Python, … Tout ça autour d’une bonne bière belge et d’environ 5000 amis barbus. Vivement le FOSDEM 2016 et son 5ème t-shirt pour tenir toute la semaine. »

Devoxx France – 8-10 avril 2015, Paris

Hervé : « Devoxx France, c’est l’occasion de découvrir de nouveaux outils, de nouvelles bibliothèques mais aussi d’avoir des retours d’expériences. »

Mix-It (16-17 avril 2015, Lyon

Mathias : « Outre le fait que Mix-It permet de prendre du recul sur son travail quotidien, les diverses conférences et ateliers sont des lieux pour rencontrer des gens passionnés et passionnants. Alors n’hésitez pas à participer à ce type d’événement ! »

Riviera Dev – 11-12 juin 2015, Sophia-Antipolis

Jonathan : « 2015, l’année du reboot de Riviera Dev. Après une dernière édition annulée faute de participants, la conférence du soleil renaît, poussée par un crowdfunding auquel nous autres sudistes nous devions de contribuer.

Si petite en renommée elle est encore, grande en qualité Riviera Dev est déjà ! Durant deux jours, les tracks sur Java et le Web s’enchainent. Et parmi les intervenants, on retrouve des pointures de Java (Rémi Forax, Emmanuel Bernard…) et de son écosystème (Tugdual Grall…), mais on découvre aussi de très prometteurs speakers (Hubert Sablonnière…). Et pour varier les plaisirs, il était aussi possible de s’attaquer aux ateliers sushis et DJaying !

Et puis parce que dans le Sud on sait recevoir, on retiendra aussi l’excellent buffet et la socca à volonté, le tout sous un soleil brûlant ! Riviera Dev, à suivre et à soutenir ! »

DockerCon – 16-17 novembre 2015, Barcelone

Charles : « Faire le déplacement à Barcelone pour la DockerCon 2015 m’a permis de sortir de mon cadre de travail habituel pour découvrir d’autres façons de travailler et échanger avec des développeurs du monde entier !

Liste des points positifs : une prise de recul sur son travail et l’environnement qui va avec, de nouvelles idées à mettre en place dans l’entreprise, l’envie de partager avec les collègues, un regain de motivation pour améliorer la qualité de son travail et sa productivité, une synergie accrue avec les développeurs qui ont fait le déplacement ensemble. »

Agile Grenoble – 19 novembre 2015, Grenoble

Benjamin : « Agile Grenoble 2015, une conférence qui permet de découvrir des méthodes utiles au quotidien pour plus d’efficacité et de convivialité dans le développement, et également pour se poser plein de questions sur nos habitudes quotidiennes! »

DevOps Day – 20 novembre 2015, Marseille

Franck : « Il est agréable dans notre région d’avoir désormais un évènement avec des intervenants de qualité, sans trop de langue de bois, et qui amène à une réflexion sur l’évolution de nos métiers et de leurs outils.

Le discours est plutôt orienté technique, avec des retours d’expériences concrets qui donnent une valeur inestimable à ce genre d’évènement. J’espère que la sauce va prendre et que la prochaine édition sera aussi bien que cette première édition. »

NDLR: le terme "bull*t" du texte original a été remplacé par "langue de bois" :-)

Nous participons également à des réunions « locales » plus courtes, en soirée,

Mars Jug – environ tous les deux mois

Olivier : « J’aime aller au MarsJug car on se fait une ou deux voitures de développeurs et on débat entre nous pendant toute la route Lambesc – Marseille !! Souvent, on trouve un speaker sympa et très accessible car c’est un JUG où nous sommes peu nombreux. Ensuite on refait un roadtrip pour rentrer avec en plus le défi de trouver un Quick ou un MacDo ouvert tard le soir. C’est la belle vie !! »

NDLR : Et les Burger King alors ? :-)

Meetups Docker – 16 avril et 16 juillet 2015, Aix en Provence

Benoit : « Les meetups Docker nous ont permis de rencontrer d’autres industriels de la région qui travaillent sur des problématiques proches des nôtres. Le retour d’expérience a été enrichissant. Ces rencontres nous ont même permis de recruter ! »

Nous avons par ailleurs présenté des sessions dans les conférences suivantes :

Agile Aix/Marseille 2015 – Aix en Provence

« Vos tests on besoin d’amour » par Benoit Sautel, qui tient le blog « Fier de coder« .

Blend Web Mix 2015  – 28-29 octobre 2015, Lyon

« Web sémantique, web de données : et si on passait à la pratique » par Pierre Col et
Julien Homo.

Julien Homo : « Pour moi l’originalité de BlendWebMix repose principalement sur sa capacité  à proposer des conférences à un public très hétérogène avec un contenu au périmètre très large. On peut à la fois écouter par exemple Laure Wagner nous raconter l’impressionnante croissance de sa société Blablacar et inversement assister au touchant témoignage de Simon Dawlat qui raconte la chute de son entreprise AppGratis et la vertigineuse descente aux enfers subie ensuite par son équipe. D’un point de vue plus technique, Stéphane Bortzmeyer nous apprend qu’il est possible de hacker directement des registres de noms de domaines tandis que le graphiste Christophe Tauziet de Facebook nous met en garde sur l’impact qu’engendre la moindre modification d’une interface vue par des milliards d’utilisateurs. Autant de sujets à la fois riches, variés et animés par des présentateurs souvent très dynamiques font pour moi de cette conférence un rendez-vous incontournable des différents acteurs du Web d’aujourd’hui et de demain. »

Enfin notre pôle Recherche a animé deux sessions pédagogiques en la personne de Ludovic Samper :

« En 2015, j’ai eu l’occasion de présenter nos travaux à deux occasions : aux élèves de l’ENS de Lyon et lors de l’école d’été WISS. C’est très plaisant de présenter nos travaux au monde de la recherche. Le travail de préparation permet toujours de mieux cerner son sujet. Et surtout, les chercheurs et les étudiants sont intéressés par les problématiques que l’on rencontre dans un contexte plus industriel que le leur. Cet échange peut être l’occasion de commencer des collaborations ou des stages. »

Conférences auxquelles Antidot a participé en 2015

Si vous êtes tentés par l’aventure, si vous voulez participer avec nous à ces évènements…

Antidot recrute !

Antidot à la Web Intelligence Summer School

WISS 2015
La Web Intelligence Summer School 2015 a eu lieu du 31 août au 4 septembre à l’Université de Saint Étienne.

La thématique cette édition 2015 était « Répondre à des questions avec le Web » :

  • Publication de données web : données liées Linked Data,  normes et techniques du web sémantique / web des données
  • Comprendre et analyser une question en langage naturel : NLP / traitement du langage naturel
  • Trouver des données pour répondre à la question et à justifier la réponse : intégration / curation / extraction de données
  • Présenter les réponses : représentation graphique et  visuelle

Vous trouverez ici le programme complet de la Web Intelligence Summer School.

Membre de l’équipe Recherche d’Antidot, Ludovic Samper y a donné mardi 1er septembre de 10h30 à 12h30 un cours de 2 heures sur les techniques d’apprentissage automatique – machine learning. Il y a parlé plus spécifiquement de classification supervisée utilisant scikit-learn, et détaillé certains algorithmes comme NB  – Naïve Bayesian, classification naïve bayésienne – et SVM – Support Vector Machine, machine à vecteurs de support.

Résultats de différents classifieurs avec scikit-learn – cliquez sur l’image pour l’agrandir

Si vous n’avez pas pu y assister, en voici le contenu (en anglais) :


This is all the materials for the course:

The tutorial is about supervised classification of text documents. I’ve presented some classical algorithms (Multinomial Naïve Bayes, Support Vector Machine) and the maths behind. To illustrate the course, I used scikit-learn library and the 20newsgroups dataset.

The slides are here:

[slideshare id=52252432&doc=wiss-ml-150831140716-lva1-app6892]

And you’ll find here the code I shown using iPython notebook:


 

Partenaires de cet événement :

Université Jean MonnetLaboratoire Hubert CurienÉcole des Mines de Saint ÉtienneTelecom Saint ÉtienneCNRSBonn UniversitätFraunhofer Institut

Continuous integration, Continuous delivery, Continuous deployment : où en est-on chez Antidot ?

L’équipe Delivery a la responsabilité de la mise en place des outils et des process de l’équipe technique chez Antidot. Dans ce cadre, elle développe puis opère les chaînes d’intégration continues de nos produits logiciels.

Je me propose de vous faire un retour d’expérience basé sur notre pratique.

De quoi parle t-on ?

L’intégration continue (continuous integration dans la littérature anglo-saxonne) implique que les développements logiciels sont régulièrement intégrés sur une branche commune sur laquelle sont automatiquement déroulées toutes les étapes de compilation et de validation.

La livraison continue (continuous delivery) est la suite logique de l’intégration continue : elle implique qu’à chaque moment on est « prêt à livrer » une version. La sortie de l’intégration continue devient donc le livrable attendu.

Le déploiement continu (continuous deployment) représente le Graal des équipes DevOps : chaque commit, s’il n’introduit pas de régression, finit automagiquement en prod.

(source IamOnDemand)

Continuous Integration

Depuis 5 ans, nous avons mis en place des chaines d’intégration continues, de plus en plus complètes.

A ce jour, chaque commit dans git sur une des branches de référence déclenche séquentiellement :

  • La compilation et les tests smalls,
  • le packaging (.deb et .rpm) et la création de dépôts dédiés à la validation,
  • des tests dits « medium » puis des tests dits « larges ».

Les dénominations de tests « small », « mediums » et tests « larges » viennent de l’excellent livre « How Google tests software », dont vous trouverez ici un résumé en français et qui propose une classification des tests en small, medium et large.

  • Un test small valide une unique fonction, avec une granularité très fine
  • Un test medium implique un ensemble de « modules » qui collaborent pour réaliser une fonction
  • Un test large implique le système entier.

Les problèmes que nous avons rencontrés lors de la mise en place de ces chaines d’intégration continue tournent autour de deux thèmes :

  • L’instabilité chronique des chaines,
  • Le temps d’exécution de ces chaines.

La solution au premier point réside dans l’analyse systématique des erreurs pour essayer d’en éliminer les causes racines. Je pense qu’on pourrait faire un article entier (et d’ailleurs je le ferai peut être) sur toutes les raisons, bonnes ou mauvaises, qui font qu’une chaine d’intégration continue est instable.

Pour le second point, nous n’avons pas à ce jour de solution satisfaisante : après avoir facilité l’écriture de tests, mis en place des outils pour les jouer automatiquement, réussi à convaincre tout le monde de l’intérêt de produire un maximum de tests, nous sommes aujourd’hui confrontés au problème de l’adhésion de tous à ces principes, et donc nos suites de tests augmentent et leurs temps d’exécution s’allongent.

D’aucuns diront que c’est un problème de riche, mais il faudra assez rapidement que nous nous attaquions à ce problème.

Continuous Delivery && Continuous Deployment

Les chaines d’intégration continue installent toutes les nuits la meilleure version disponible (RC pour « Release Candidate ») dans un environnement simulant la production.

À tout instant, une version est donc prête à livrer, et en ce sens nous respectons le Continuous Delivery.

En pratique, nous livrons une version toute les semaines et chacune de ces versions est mise en production.

Qu’est ce que signifie livrer pour nous ?

  • positionner un numéro de version sur un SHA-1 git,
  • communiquer sur la disponibilité de cette version (mail, tweet),
  • communiquer (Release Notes) sur le contenu fonctionnel de la version : nouvelles fonctionnalités, corrections de bugs…
  • mettre à disposition des paquets dans un dépôt stable.

Pourquoi doit on livrer ?

La question peut surprendre, mais dans un monde où une part significative des développements est exploitée en mode Cloud, la notion de numéro de version peu avoir un coté archaïque. Si l’on applique à la lettre les principes du Continuous Deployment, la version en production est la dernière qui a passée toutes les validations, et la notion de livraison telle que décrite ci dessus s’estompe.

Pour autant, nous ne somme pas prêt à abandonner la notion de livraison car en plus d’opérer notre propre solution dans notre datacenter, nous livrons aussi  nos logiciels en licence et nous fournissons notre plateforme à des partenaires qui construisent des solutions par dessus.

Dans ces deux derniers cas, les clients peuvent attendre des fonctionnalités ou des corrections de défauts, qui doivent être corrélées à des versions.

Le Delivery Train

La pratique de livrer systématiquement toutes les semaines la meilleure version possible (la dernière ayant passée avec succès tous les tests disponibles) est inspirée du « Delivery train » prôné par Spotify. Par ailleurs, c’est un premier pas vers le « Continuous Deployment ».

Avant la mise en place du Delivery Train :

  • la livraison d’une version, son périmètre fonctionnel, sa date de sortie était le résultat d’âpres négociations entre développeurs et chefs de projet, arbitrées par l’équipe Delivery.

Depuis la mise en place du Delivery Train, la livraison est systématique le vendredi et cela a :

  • enlevé du travail inutile et chronophage de négociation de date et de contenu,
  • rassuré tout le monde : si on rate un créneau pour une correction, le suivant n’est jamais que dans une semaine dans le pire des cas,
  • fortement amélioré l’automatisation du mécanisme de livraison : ce sont les effets bénéfiques du classique : « if it hurts, do it more often » cher à toutes les pratiques d’automatisation
  • et donc bien évidemment, facilité le non respect de la règle : en cas d’urgence (bug critique…), nous relivrons immédiatement. Et les gains en automatisation du processus de livraison facilitent cette livraison supplémentaire.

Continuous Deployment

Antidot ne fait donc pas aujourd’hui de Continuous Deployment. Mais un des effets bénéfiques du Delivery Train est que l’on y va doucement mais sûrement, poussés par le train.

En effet, la mise à disposition toutes les semaines d’une nouvelle version, nous a poussé à essayer de la mettre en production dans la foulée.

Nous sommes à nouveau dans un mode « if it hurts do it more often » :

  • nous avons mis à plat les processus de mise en production,
  • nous avons systématisé un calendrier,
  • nous sommes actuellement en train de travailler à rendre ce process aussi automatique que possible.

À moyen terme notre objectif sera donc une livraison hebdomadaire de version et le déploiement automatique de cette version sur notre production.

Je ne sais pas dire aujourd’hui si nous irons vers le Continuous Deployment au sens strict de la définition. Je dirais que nous n’en n’avons jamais été aussi près, et je vous en reparlerai dans quelques mois, lorsque nos objectifs moyens termes seront atteints.

Références :

Ship It Day Antidot – première édition !

Les 19 et 20 mars derniers se tenait le premier « Ship It Day » dans les locaux de la R&D d’Antidot à Lambesc (13).

Le Ship … quoi ?

A l’origine initié par la société Atlassian, le Ship It Day est une opportunité donnée aux employés de travailler en 24 heures sur un projet de leur choix, en rapport avec le produit et l’activité de l’entreprise, en vue de le livrer à l’issue de la journée, avec une seule règle : « Pas de règles ! ».

Cette manifestation est une occasion pour l’entreprise de promouvoir l’innovation en mettant différentes équipes en concurrence. Oui, mais dans quel but ?

La raison est simple : qui n’a jamais entendu ce genre de remarques à la machine à café ?

« Ce serait vraiment pratique que cet outil permette de faire ça, ça et puis aussi ça »

« Je ne comprends pas, ce produit là ne se vend pas autant qu’on aimerait »

« Pfff, je ne me souviens jamais comment fonctionne cette appli… en même temps elle n’est pas vraiment intuitive ! »

En effet, pendant le Ship It Day, ces équipes vont enfin pouvoir développer ce plugin qui manque depuis si longtemps, repenser une fonctionnalité que personne n’utilise, redessiner une interface, etc.

Or le pilotage quotidien de ces équipes, la pression liée aux cycles de développements dans le respect scrupuleux de la roadmap ne permet guère de laisser parler la créativité des collaborateurs…

Pourquoi c’est cool ?

ShipItDayLe Ship It Day est avant tout une aventure humaine, ludique, faisant de l’évènement un vecteur d’émulation très fort. Cela permet de faire une pause dans le train-train quotidien, tout en avançant rapidement sur des projets, au final relativement aboutis.

C’est également l’occasion pour les collaborateurs, en sortant du cadre de travail habituel, de travailler et d’échanger avec des personnes qu’ils n’ont pas toujours l’habitude de côtoyer. Une réelle synergie inter-équipes se crée alors dans une ambiance très conviviale.

Enfin, certains prototypes réalisés au cours du Ship It Day pourront devenir des fonctionnalités du Produit, qui, une fois industrialisées, seront déployées en production.

Une première chez Antidot ?

Antidot est cependant coutumier du fait, puisqu’il s’agit en réalité du troisième évènement de ce type en trois ans, avec deux précédentes éditions sous la forme de “Hackathon”. À deux reprises déjà, il s’agissait de proposer un prototype destiné à faire avancer le Produit, réalisé à l’issue d’un marathon de développement d’une semaine,.

Néanmoins, bien que suscitant un réel intérêt au sein des équipes de développement, la durée pour ces hackathons s’est finalement avérée trop longue pour pouvoir les maintenir et les renouveler à un rythme régulier.

Cette année, la société a donc adopté le format Ship It, plus court, pouvant ainsi être reconduit régulièrement.

Comment ça marche ?

Le Ship it se déroule en plusieurs phases :

J – 2 mois : Lancement

La date à laquelle aura lieu le Ship It est annoncée aux collaborateurs.

J – 1 mois : Ship It order

Les collaborateurs peuvent proposer des projets. Il n’y a pas de contraintes sur le nombre de projets soumis par personne, ni sur le thème sur lequel ils vont participer.

Un projet peut même être proposé 5 min avant le début du Ship It Day, le jour J.

J – 1 semaine : Brown bag

Les personnes porteuses d’un ou plusieurs projets et ayant besoin d’autres collaborateurs peuvent, uniquement s’ils le souhaitent, présenter leur projet à l’ensemble de la société afin de recruter et constituer leur équipe.

Jour J :

Chaque équipe annonce le thème de son projet et la composition de l’équipe

Le concours débute un jeudi matin à 11 h pour se terminer le lendemain à la même heure.

Durant ces 24 h, ce sont les managers qui se chargent de l’intendance : pauses avec café / gâteaux / bonbons, pizza party le soir, petit déjeuner le matin, etc.

C’est une occasion unique de pouvoir se faire servir une bière par son manager !  😉

Les équipes constituées préparent ensuite des démonstrations de 5 min sur leurs prototypes, en vue de les présenter à l’ensemble de la société. Une fois les démonstrations terminées, l’ensemble des collaborateurs peut voter pour élire le projet vainqueur du Ship It Day. S’en suit alors une « party » digne de ce nom, afin de célébrer les vainqueurs et l’ensemble des participants à l’évènement.

A quand le prochain?

KeepCalmShipItAprès cette première édition fin mars, la prochaine est prévue les 18 et 19 juin prochains. Au total, ce seront donc quatre Ship It Day qui seront organisés par an, au rythme d’un par trimestre.

Lors du Ship It Day du mois de mars, entre les collaborateurs sur les pistes de ski, en déplacement professionnel ou tout simplement indisponibles, les projets ont principalement été réalisés par les équipes de la R&D.

Mais le Ship It Day a bien évidemment vocation à faire interagir le maximum de collaborateurs, quelles que soient leurs équipes de rattachement : chefs de projet, staff marketing, support client, etc. Nul doute que la prochaine édition verra encore plus de collaborateurs dans les équipes engagées.

Vivement la prochaine édition !

Et vous, dans votre entreprise, ça se passe comment le Ship It Day ? 🙂

P.S. : si notre approche autour des Ship It Days ou des brown bags vous intéresse et si vous êtes tenté de nous rejoindre cela tombe bien, on recrute ! Et pour ne rien vous cacher, nous avons expliqué sur ce blog comment se déroule le processus de recrutement à la R&D d’Antidot.

Chez Antidot, on a adopté les « brown bags ». Et chez vous ?

Il y a quelques années, lors d’une conférence Mix-IT, j’ai entendu parler des initiatives de Brown Bag Seminar. L’idée est d’inviter quelqu’un dans votre entreprise pour qu’il vous présente un sujet et pour le remercier, vous lui offrez son déjeuner. J’ai trouvé l’idée géniale, je voulais ça chez nous !

Mais retour sur terre, notre centre de R&D est situé à Lambesc, et des baggers dans le coin, il n’y en a pas des masses ! Attention, Lambesc, c’est génial ! On joue à la pétanque, on se fait des BBQ, on part courir ou faire du VTT dans la nature en 30 secondes depuis nos locaux, on n’a aucun bouchon sur la route (il faut tout de même se méfier des sangliers) mais pour trouver des personnes qui ont des sujets techniques qui pourraient nous intéresser… ce n’est pas Paris.

Alors comment faire ?

Saison 1 : Video Brown Bag

Le Web regorge de vidéos présentant les sujets qui nous intéressent. Plutôt que tous les regarder dans notre coin, pourquoi ne pas nous regrouper pour les regarder ensemble ? L’idée est lancée. Je crée un UserVoice pour rassembler les idées de tout le monde, on vote et on regarde chaque lundi midi la plus populaire. C’est une période sympa où nous avons entre autres découvert Gradle, Ceylon, OAuth 2, Play Framework… mais le côté vidéo n’est pas assez convivial et l’initiative commence à s’essouffler. En bon agiliste, je me dis « rétrospective, prise d’information et action », il faut faire de vraies présentations avec un présentateur physiquement présent.

Saison 2 : Home Made Brown Bag

Toujours la même question : où trouver des personnes capables de présenter des sujets tech qui peuvent intéresser du monde chez nous ? Et une nouvelle révélation ! L’idée révolutionnaire que l’on n’attendait pas : une personne qui travaille déjà chez nous !

Sur notre site de Lambesc nous avons des profils très différents ; depuis ceux qui sont fan du noyau Linux jusqu’à ceux qui adorent le CSS, en passant par C++, Python, Java, GWT, Javascript, Puppet, Jenkins, CMake et j’en oublie beaucoup. Convaincu de mon idée, je lance la saison 2, j’assure moi même le premier épisode : une présentation sur Tribal Leadership. Nous avons ensuite une présentation sur DITA, une sur Java 8 mais très vite (beaucoup plus vite), nouvel essoufflement. Du coup, rétrospective, prise d’information…

Trois causes principales :

  • le midi, c’est sympa de se faire un resto : ben oui, on est en France quand même.
  • le midi, on fait de la pétanque, du foot, du basket, on va courir, nager, on joue à des jeux de société… et il n’y a que 5 midis par semaine pour tout caler.
  • ça nécessite de préparer des slides.

Saison 3 : Home Made Brown Bag without Brown Bag aka « Weekly Dev »

Devant mon désarroi sur l’échec des Brown Bags, mon directeur technique me dit : « Et si on le faisait tous les mercredis de 11h30 à midi » ? Au début je me dis que c’est n’importe quoi, je ne vais pas manger à 11h30, c’est bien trop tôt. Mais tentons !

L’idée est simple : chaque mercredi, toujours à la même heure, toujours au même endroit, des personnes convergent de leurs postes respectifs et se rassemblent. On se regarde tous et on se pose cette question existentielle : « Qui a un sujet à présenter ? ».

Au début, quelques personnes trouvent des sujets. Mais même s’il y a des personnes qui aiment expliquer, il y a aussi des personnes plus réservées. Nous avons de nouveau atteint le jour où nous n’avions plus d’idée de sujet. Alors je tente la question inverse : « Qui aimerait qu’une autre personne ici lui présente un sujet ? » et c’est l’avalanche d’idées. Tout le monde est très curieux des domaines connus par d’autres.

Et depuis ce jour, les mercredis se succèdent avec des sujets complètement disparates et toujours passionnants. J’apprends des choses sur l’architecture des processeurs multi-coeurs, sur le protocole HTTP2 fraîchement sorti, sur la difficulté d’écrire un handler de signal en C, sur la mise en place d’un LogStash, sur l’architecture nécessaire à faire tourner un cluster Cassandra… Il y a aussi les fois où nous présentons ce que nous avons mis en place techniquement dans notre produit sans avoir à tenir un discours compréhensible par un non développeur car on est entre nous, les passionnés du code.

Enfin, par effet de bord, le Weekly Dev casse les murs entre les équipes, permet d’échanger, de débattre, de polliniser et nous permet de mieux nous connaître les uns les autres, et finalement, c’est ce que je préfère !

source : Dilbert, by Scott Adams

P.S. : si vous êtes tenté de nous rejoindre cela tombe bien, on recrute ! Et pour que vous sachiez comment se passent les recrutements à la R&D d’Antidot, nous avons expliqué tout le processus.

Le processus de recrutement dans les équipes de R&D d’Antidot

Le recrutement est un processus difficile dans lequel il n’existe pas vraiment de méthode scientifique ou de recette à suivre pour être sûr de ne pas se tromper. Il est pourtant important que nous puissions déterminer si vous pourrez relever les défis qui vous seront proposés une fois formé à nos outils.

De son côté, le candidat cherche souvent des réponses à des questions telles que :

  • Le poste qu’on vous propose est il à la hauteur de ses attentes ?
  • L’environnement de travail proposé et ses futurs collègues forment-ils un écosystème riche dans lequel il va à la fois pouvoir partager ses connaissances et en développer de nouvelles ?

Depuis plus de 15 ans les équipes d’Antidot peaufinent le processus de recrutement afin d’être capables d’avoir une intime conviction sur l’adéquation de chaque candidat aux postes proposés. En cas de doute, nous préférons écarter une bonne candidature, plutôt que de proposer un poste à quelqu’un en risquant d’aboutir à un échec en début de collaboration. Nous refusons d’attendre la période d’essai pour vérifier les compétences de nos nouveaux employés.

Les collaborateurs d’Antidot travaillent tous en confiance avec beaucoup d’autonomie et de responsabilités. Quand nous faisons une offre à quelqu’un, c’est que nous pensons que toutes les conditions sont remplies pour que la collaboration se passe bien.

Pour cela, lors du processus de recrutement, nous vous ferons échanger avec le plus de personnes possibles (futurs collègues et responsables) dans une grande variété de contextes afin de tenter d’établir une cartographie à 360° de votre profil. Réciproquement vous aurez une vision claire du poste à pourvoir et de nos méthodes de travail.

Si vous postulez à un poste dans la R&D d’Antidot, vous suivrez ce parcours avec nous. Si vous franchissez toutes les étapes nous aurons le plaisir de vous faire une offre de collaboration.

Sélection préliminaire

Dès réception de votre dossier, le manager en charge du recrutement, assisté éventuellement d’autres collaborateurs, fait une première étude de votre lettre de motivation et de votre CV.

Nous cherchons dans cette étape à vérifier que vous êtes intéressé, voire passionné, par les postes que nous proposons. Nous cherchons moins à vérifier que vous maitrisez toutes les technologies attendues qu’à nous assurer que vous avez une bonne culture du domaine, l’envie d’apprendre et de travailler avec nous pendant le plus longtemps possible.

Un dossier clair, synthétique et bien rédigé constitue un atout lors de cette étape.

Si le manager détecte du potentiel dans votre candidature, il vous contacte pour planifier un premier entretien téléphonique.

Entretien téléphonique

Un premier contact, d’une durée d’environ 30 minutes, est mené par le futur responsable hiérarchique direct du candidat, parfois accompagné d’un expert du métier (développeur web, rédacteur technique, ingénieur système…).

C’est l’occasion pour vous d’en savoir plus sur Antidot et le poste à pourvoir ; n’hésitez pas à poser des questions.

Les éléments recherchés lors de cette étape sont :

  • Esprit de synthèse
  • Clarté de l’expression
  • Bonne connaissance des éléments présentés dans le dossier de candidature
  • Intérêt pour le poste et le domaine d’activité

Il arrive qu’un entretien ne suffise pas à évaluer précisément votre candidature ; dans ce cas un second entretien avec d’autres interlocuteurs vous est rapidement proposé.

Si nous pensons que votre candidature présente suffisamment de points forts, nous vous convoquerons pour une journée de tests et d’entretiens.

Journée de tests et d’entretiens

Cette journée a lieu sur site, dans nos locaux de Lambesc, à proximité d’Aix en Provence.

L’objectif de cette étape est de vous faire rencontrer un maximum de personnes et de vous confronter à des tests représentatifs du travail quotidien qui vous attend si vous travaillez chez nous. Après l’accueil autour d’un café de bienvenue, les tests commencent :

  • Si vous postulez pour un poste de développeur, vous coderez sous la supervision de nos ingénieurs expérimentés dans un ou plusieurs langages mis en avant dans votre CV.
  • Si vous candidatez à un poste d’Ingénieur système, vous aurez à résoudre des problématiques représentatives de la production.
  • Si vous êtes rédacteur technique, vous produirez des documents structurés …

La journée sera interrompue à quelques occasions :

  • Antidot vous invitera à partager un repas avec vos futurs collègues. Vous pourrez alors faire plus ample connaissance et discuter de sujets en rapport avec le poste … ou de tout autre chose : vos passions, vos hobbies…
  • L’entretien d’équipe où vous rencontrerez les membres de votre future équipe.
  • Les entretiens avec vos futurs managers.

A l’issue de cette journée nous ferons ensemble un point sur votre candidature, le résultat des tests, votre perception d’Antidot et notre retour sur votre prestation. Ce dernier entretien sera l’occasion d’aborder les modalités pratiques de collaboration. Vous pourrez également aborder tout point que vous souhaiteriez détailler.

L’objectif de la journée est d’apporter des réponses aux questions suivantes:

  • Maîtrisez vous les éléments technologiques mis en avant dans votre dossier ?
  • Avez vous la capacité d’apprendre, d’échanger avec nos équipes ?
  • Que faites vous quand vous ne savez pas résoudre un problème ?
  • Que faites vous quand nous vous suggérons une approche alternative ?
  • Votre personnalité vous permettra-t-elle de vous intégrer au sein de nos équipes ?

De votre côté, après avoir travaillé au sein de nos équipes pendant une journée entière, vous aurez une bonne idée du travail quotidien chez Antidot, des relations entre les collaborateurs. Désormais informé précisément du poste à pourvoir, vous pourrez ainsi valider votre envie de relever avec nous les défis quotidiens inhérents à la production de logiciels de qualité.

Épilogue

Quelques jours après cette journée de tests, nous reviendrons vers vous.

Si tout s’est bien déroulé nous vous ferons une offre de collaboration. Nous espèrerons alors que, séduit par notre culture et par le poste, vous l’accepterez. Ce qui permettra à Antidot de compter un collaborateur passionné de plus !

equipe-levier

 

Moteurs de recherche : faites la chasse aux requêtes sans réponse ! [3/3]

Dernier billet de notre série consacrée aux bonnes pratiques pour réduire au maximum les  recherches sans réponse : nous allons voir qu’il est possible d’être moins strict dans les combinaisons de mots-clés et aussi de mettre en place des rebonds vers du contenu pertinent  en cas de requête vraiment sans réponse.

3. Requête trop précise – Recherche optionnelle

Parfois, la requête ne donne pas de résultats parce qu’elle contient de nombreux mots-clés dont la combinaison contraint fortement les résultats.

Il est utile, dans ces cas là, de proposer une recherche optionnelle où tous les mots-clés ne sont pas obligatoires : le moteur de recherche utilise alors un opérateur OU au lieu de ET entre les différents mots de la requête. Le mécanisme de pertinence fait en sorte que les documents contenant le maximum de mots-clés parmi ceux cherchés soient proposés en priorité.

Le CSA propose un mode de recherche optionnel sur son site web. En l’absence de rapport 2014, la recherche «Rapport annuel 2014 » propose des rapports plus anciens.

3.1.ScreenshotCSACliquer pour agrandir l’image

Compte tenu du bruit potentiel que la recherche optionnelle peut engendrer, il est tout de même recommandé de commencer par une requête classique et, en cas de non réponse seulement, d’exécuter une requête optionnelle en informant l’utilisateur du fait que l’on a élargi sa recherche.

4. Contenus non indexés

Parfois, vos utilisateurs cherchent des informations que vous n’avez pas indexées dans le moteur de recherche, comme par exemple l’adresse ou numéro de téléphone du service client.

Dans ce cas, il est utile de prévoir un comportement approprié du moteur de recherche qui pourra rediriger l’utilisateur vers la page concernée de votre site web. Il suffit pour cela d’intercepter un certain nombre de mots -clés pour gérer une redirection vers une page particulière, au lieu de laisser le moteur exécuter sa recherche.

Malheureusement dans certains cas, l’utilisateur cherche vraiment un contenu que vous n’avez pas. Pour autant, même dans ces cas là il ne faut pas négliger votre page de réponse.

Voici quelques éléments que vous pouvez fournir et qui peuvent aider l’utilisateur à rebondir vers d’autres contenus :

  1.  Proposer l’aide d’un conseiller :
    ssrep-assistanceCliquer pour agrandir l’image
  2. Proposer la liste des contenus les plus consultés
  3. Proposer un hit-parade des requêtes les plus fréquentes :ssrep-hitparadeCliquer pour agrandir l’image
  4. Proposer une liste éditorialisée de contenus, par  exemple les meilleures ventes pour un site marchand :ssrep-meilleuresventesCliquer pour agrandir l’image

Les exemples ci-dessus proviennent du site Oreca Store, spécialisé dans le sport automobile et où, bien que le catalogue soit extrêmement riche, on ne trouve pas de « table basse en chêne » 😉

Dans tous les cas, améliorer la pertinence de votre moteur de recherche et optimiser ses réponses est un processus continu. Une analyse régulière de vos requêtes sans réponse vous permettra d’enrichir vos dictionnaires, d’identifier les cas qui posent régulièrement problème, et de mettre en place les fonctionnalités adéquates.

Il n’est pas nécessaire d’y passer beaucoup de temps, et cela paye vraiment : 10 minutes par semaine sont largement suffisants, et vous constaterez aussitôt une amélioration réelle !

N’hésitez pas à nous faire part, en commentaire, de vos propres astuces pour satisfaire au mieux les requêtes de vos clients, ou si vous avez déjà rencontré un cas d’usage non couvert dans ces billets !

Moteurs de recherche : faites la chasse aux requêtes sans réponse ! [2/3]

Nous avons vu dans un précédent billet comment traiter automatiquement les erreurs de saisie et fautes de frappe.

Examinons maintenant un autre cas de figure :

2. Les requêtes utilisant un vocabulaire différent du vôtre

Dans ce cas l’utilisateur ne s’est pas trompé dans sa requête, mais a utilisé un vocabulaire qui n’est pas celui de vos documents ou fiches produits. Plusieurs scenarii sont possibles :

a. L’utilisation de synonymes ou abréviations

Les utilisateurs peuvent utiliser des mots différents de ceux de vos fiches, pourtant ils désignent la même chose : « gratte » au lieu de « guitare » pour un musicien de rock, « voiture » ou même « bagnole » pour « automobile », « loi Aubry » ou « loi des 35 heures » pour « loi n° 98-461 ».

Une solution basique serait de surcharger manuellement vos documents avec les différentes formes possibles des mots utilisés : cela fonctionnerait, mais c’est loin d’être la solution optimale.

Utilisez plutôt un dictionnaire de synonymes. Démarrez avec une simple liste à plat de mots ou d’expressions et listez les synonymes métier, les abréviations fréquemment employées… Ces équivalences seront appliquées automatiquement par le moteur de recherche pour optimiser la réponse à vos utilisateurs.

Chez Decathlon le terme « hula-hoop » désigne aussi un « cerceau » :

2.1.ScreenshotDecathlonCliquer pour agrandir l’image

Vous n’avez pas besoin de constituer la liste d’une seule traite, commencez par une première base, que vous enrichirez au fur et à mesure.

 

b. L’utilisation de concepts parents

Vos utilisateurs peuvent parfois utiliser des termes plus larges que ceux très spécifiques utilisés dans vos contenus. Mais on ne peut pas parler de synonymes au sens strict. Un utilisateur peut par exemple chercher « voiture » là où vos documents mentionnent des « cabriolets », ou encore chercher « sport de raquette » quand vos documents évoquent spécifiquement le « tennis », le « badminton » ou le « ping pong ».

Dans ce cas là, il est préférable de passer par un dictionnaire de concepts hiérarchisé, ou thesaurus.

A la différence de la liste de synonymes mentionnée plus haut, le thesaurus sert à organiser des termes de manière hiérarchique avec plusieurs niveaux d’information. On parle dans ce cas de concepts parents ou enfants.

Les moteurs de recherche utilisent ces dictionnaires pour répondre de manière précise à des requêtes larges ou floues, mais en aucun cas ils ne doivent répondre de manière générique à une requête très précise : il faut en effet prendre comme hypothèse que l’utilisateur qui cherche un terme très précis souhaite justement obtenir un contenu adapté.

Sur le site « Croquons la vie » de Nestlé, les « snacks » désignent les « burgers » , « tartines » et « croque-monsieur » :

2.2.ScreenshotNestléCliquer pour agrandir l’image

Les moteurs de recherche de dernière génération savent prendre en compte les niveaux de hiérarchie dans le classement par pertinence de leurs résultats.

Ainsi un moteur de recherche efficace, comme Antidot Finder Suite, va d’abord proposer des fiches qui contiennent exactement le mot recherché avant de proposer d’autres fiches qui contiennent des concepts enfants.

c. Compréhension du langage naturel

Dans d’autres cas les utilisateurs vont, en plus des mots clés significatifs, utiliser des expressions pour mieux qualifier leurs requêtes : « Inférieur à un certain prix », « Postérieur à une certaine date »… et se retrouvent sans réponse alors que avez du contenu adapté.

Prenons l’exemple suivant d’un site de e-commerce: si un visiteur saisit « Chaussures à moins de 100 euros« , cette requête risque de ne pas donner de résultats parce qu’il n’y a probablement pas de fiches de chaussures contenant « à moins de ». Et elle ne proposera pas des chaussures à 50 euros, parce que leur fiche ne contient pas « 100 ».

Il est facile pour nous humains, dotés d’un cerveau très puissant, d’interpréter la recherche et de se rendre compte qu’en fait la recherche porte simplement sur des chaussures, avec un filtre sur leur prix. Mais c’est bien plus compliqué lorsqu’il s’agit de l’expliquer au moteur de recherche !

Il existe donc, pour gérer ce genre de cas, des modules de réécriture qui servent à identifier certaines formes de requêtes et à les transmettre au moteur de recherche avec la syntaxe qu’il sait gérer au mieux.

Dans notre cas, l’expression « à moins de 100 euros » se retrouve réécrite en filtre : « prix < 100 », permettant ainsi au moteur de trouver les résultats pertinents.

 

d. Information existante mais pas sous forme de mots-clés

Dans certains cas, l’information recherchée est présente dans vos contenus, mais pas sous forme de plein texte.

Dans un catalogue de produits alimentaires par exemple, des clients peuvent rechercher le mot-clé « bio ». Mais si l’information n’existe que sous forme de case à cocher Oui / Non dans le catalogue, le moteur ne va pas retrouver le mot-clé en tant que tel dans les fiches des produits.

Le client n’aura donc pas de résultats alors qu’il existe de nombreux produits susceptibles de l’intéresser.

Dans ce cas, un traitement est à prévoir en amont. Il faut prévoir des mécanismes d’enrichissement de vos contenus qui ajoutent les mots-clés nécessaires à vos fiches avant leur indexation. Ces traitements peuvent directement être pris en charge par le moteur de recherche.

Nous verrons la semaine prochaine comment traiter les cas de requêtes sans réponse qui subsisteraient encore après mise en oeuvre des bonnes pratiques que nous vous avons présentées.