Catégorie : Interviews et témoignages

2023 commence merveilleusement bien pour Hightest ! Nous avons l’honneur d’accueillir une nouvelle personne dans notre dream team, Alexandrine Philip Brutel. Et qui plus est, nous avons le plaisir de vous livrer ce passionnant témoignage issu de son expérience en qualité logicielle.

Bonne lecture !

La cybersécurité est un sujet crucial dans un monde de plus en plus connecté, où la plupart des informations sont exposées sur internet. Il est donc nécessaire de prévenir le risque, se protéger, détecter, alerter, répondre et remédier à la cybermenace.

Les entreprises et les particuliers doivent prendre conscience des risques liés à la cybersécurité et prendre les mesures nécessaires pour se protéger.

Pourquoi est-ce que je dis tout ça ? Parce que, pour en avoir fait l’expérience, je sais que ce genre de problème n’arrive pas qu’aux autres.

Etions-nous préparés à une cyberattaque ?

Nous étions informés de l’existence de ces phénomènes malveillants, mais malgré tout, non préparés. Que peut-on faire sans l’accès à nos sessions ? Les premiers instants il y a une sorte d’incompréhension. L’attaque a eu lieu dans la nuit ou au petit matin, pourtant, vers 7h personne ne sait encore ce qu’il s’est passé. Impossible de se connecter, que pouvons-nous faire, nous qui avons heureusement fermé nos sessions et sommes déconnectés du système ? Nous nous sentons démunis, je me sens démunie…

Que s’est-il passé ?

Que se passe-t-il ce 24 janvier 2019 ?

Altran, le groupe dans lequel nous sommes consultants, vient de subir une attaque via un « crypto locker », appelé aussi ransomware. Un ransomware est un type de logiciel malveillant ayant pour but de prendre en otage les fichiers d’un ordinateur ou d’un réseau informatique en les chiffrant. Une rançon est alors demandée pour acheter la clé de chiffrement afin de pouvoir récupérer ses fichiers.

Cette attaque a été exécutée grâce à un « code inédit indétectable[1] » par les moyens mis en œuvre par le groupe pour se protéger.

Les sessions restées ouvertes sont une menace de propagation de ce ransomware.

Des conséquences importantes pour Altran :

• La première, l’obligation de déconnecter ses systèmes d’information (SI) pour protéger l’ensemble de ses clients et ses propres applications de la propagation de ce virus.
• La création d’un nouveau protocole de restauration spécifique par un fournisseur mondial de services.
• Une récupération très lente, beaucoup trop lente de ses données.
• Une perte financière sèche, plus de 20 M d’euros, à 1 mois, fin février 2019 [1]
• Des rumeurs sur le paiement éventuel d’une partie de la rançon en bitcoins.
• Des répercussions importantes sur l’organisation même du groupe (Surcharge de travail pour le SI, modification de l’organisation de la TRA…)

La TRA dans tout ça ?

La TRA (Tierce recette applicative), totalement externalisée, se retrouve brutalement à l’arrêt, nécessitant des adaptations rapides avec tous les problèmes inhérents qui peuvent survenir.

Nous travaillons pour la plupart sur des VM (machines virtuelles) via un accès Altran. La déconnexion du SI bloque tous les accès. Comment honorer les délais de livraison des campagnes de tests, des robots d’automatisation, des stratégies à mettre en place, bref, de toutes les demandes clients sans accès à nos postes de travail ?

En 2019, la pandémie n’étant pas encore passée par là, le télétravail reste minoritaire, exceptionnel, voire inexistant. Et pourtant, il va falloir trouver une solution rapide et adaptée à chaque projet. Ceux pour lesquels le télétravail est possible ont pour consigne de rentrer chez eux, emportant sous le bras le matériel de l’époque, des PC fixes ! Pour tous les autres projets externalisés, la solution est de se rendre chez le client.

L’externalisation, qui est alors une solution formidable, devient une solution à double tranchant. L’éloignement des sites clients accentue la difficulté d’une réaction rapide, avec toute la logistique liée aux déplacements des uns et des autres à mettre en place.

Les projets sur lesquels intervient le reste de la TRA se situent à Paris, soit à 350 km. Il faut alors déplacer les consultants, les loger, mais encore faut-il que les locaux des clients permettent cette arrivée massive ! Nous serons donc répartis sur 2 sites, Paris (logés sur place) et Angers (avec des aller/retour quotidiens de

135 km de distance entre Rennes et Angers).

Nous alternerons ces 2 solutions, et nous ferons tous ces trajets, accompagnés d’une augmentation du volume horaire de nos journées, des multiples difficultés de gestion des éléments personnels (enfants, famille…), mais nous n’abandonnerons pas nos projets.

L’attaque dure, et pendant 4 semaines, nous nous plierons à cette nouvelle organisation.

Et après ?

Des solutions pour que cela ne se reproduise jamais !

Y a-t-il eu paiement ou non ? La création d’un nouveau protocole de restauration spécifique par un fournisseur mondial de services a-t-elle été suffisante ?

Cette réponse restera la réponse officielle annoncée par le groupe : Aucun paiement n’a été fait, seulement des discussions avec les attaquants.

« Concernant la rançon, si nous avions payé nous vous dirions que ce n’est pas le cas, et si nous n’avions pas payé nous vous dirions la même chose » plaisante le dirigeant[2]. « En revanche, nous avons communiqué avec les attaquants. Discuter avec eux, cela permet notamment de comprendre leurs véritables intentions. »[3]

En revanche il a bien été créé un nouveau protocole de restauration.

Quoi qu’il en soit, une réflexion sur le long terme se pose et des solutions adaptées sont à mettre en place.

Des questions essentielles doivent se poser pour Altran comme pour toutes les sociétés, telles que :

1. Qu’est-ce que la cybersécurité et pourquoi est-elle importante pour les entreprises et les particuliers ?
2. Quelles sont les principales menaces en matière de cybersécurité auxquelles les entreprises et les particuliers sont confrontés ?
3. Comment les entreprises et les particuliers peuvent-ils se protéger contre les cyberattaques ?
4. Quels sont les outils et les technologies les plus efficaces pour la cybersécurité ?
5. Comment les utilisateurs peuvent-ils se protéger contre les attaques de phishing et les escroqueries en ligne ?
6. Comment les entreprises peuvent-elles sensibiliser leurs employés à la cybersécurité et promouvoir des pratiques de sécurité ?
7. Comment la cybersécurité a-t-elle évolué au fil des ans et comment est-elle susceptible de changer à l’avenir ?
8. Quels sont les rôles et les responsabilités des gouvernements, des entreprises et des individus en matière de cybersécurité ?

Toutes ces questions ont abouti au renforcement des protocoles de sécurité accompagnés de grandes campagnes d’information récurrentes. Des tests obligatoires de sécurité sont mis en place avec un taux de réussite supérieur à 75% demandé. Outre ces actions, de nombreux éléments confidentiels sont également exploités et mis en œuvre.

Cette expérience enrichissante, vécue personnellement m’a montrée les dangers réels des cyber attaques. Des attaques insidieuses préparées bien en amont de leur émergence, pour Altran, les attaquants étaient présents dans le système depuis le 27 décembre, avec comme porte d’entrée une application web mal configurée utilisant un mot de passe d’accès par défaut[3]. Cette attaque a, pour ma part, mis en lumière toutes les problématiques engendrées pour le groupe, mais également les difficultés au quotidien pour chacun de nous. Je me dois d’avoir un regard différent sur ces cybermenaces, ce qui m’amène à la conclusion suivante sur la cybersécurité au sens large que nous sous-estimons trop souvent.

Conclusion : la cybersécurité et son avenir

La cybersécurité a connu une évolution rapide au fil des ans, en raison de la croissance exponentielle de la technologie de l’information et de l’utilisation de l’internet dans toutes les sphères de la vie. Les menaces de sécurité ont augmenté en nombre, en sophistication et en impact, et les mesures de cybersécurité ont dû s’adapter pour y faire face.

L’évolution des moyens de protection

Au début de l’ère de l’informatique, la sécurité informatique était largement axée sur la protection physique des systèmes et des réseaux. Les pare-feux et les antivirus étaient les principales solutions de sécurité mises en place. Cependant, à mesure que les réseaux ont augmenté en taille et en complexité, la cybersécurité est devenue plus importante. Les systèmes de détection d’intrusion ont été mis en place pour détecter les activités malveillantes, et les solutions de sécurité basées sur les signatures ont été développées pour identifier les logiciels malveillants connus.

Cependant, ces solutions se sont avérées insuffisantes face aux nouvelles menaces émergentes, telles que les attaques de déni de service distribué (DDoS), les attaques par phishing et les attaques de logiciels malveillants sophistiqués. Les organisations ont donc commencé à adopter des mesures plus avancées, telles que la surveillance des journaux d’activité, la détection des menaces avancées, comme des logiciels capables de détecter les comportements suspects sur un réseau et de les signaler aux administrateurs. Ces logiciels détectent les anomalies pouvant être des signes avant-coureurs d’une attaque de ransomware, permettant ainsi aux administrateurs de réagir rapidement pour limiter les dommages. D’autres mesures sont également mises en place, telles que la cryptographie et la segmentation des réseaux. Cette dernière implique la division du réseau en segments distincts, chacun avec ses propres règles d’accès et de sécurité. Cette approche limite la propagation des attaques de ransomware en isolant les parties infectées du reste du réseau. Les autres moyens techniques sont renforcés et peuvent inclure l’utilisation de solutions de plus en plus sophistiquées d’antivirus (EDR, XDR, …), du patch management[4] des logiciels et des systèmes (à partir d’un centre logiciel par exemple), de la supervision des équipements, en particulier les plus critiques.

Et demain ?

À l’avenir, la cybersécurité continuera à évoluer pour faire face aux menaces toujours plus sophistiquées des cybercriminels. Les entreprises et les gouvernements devront investir davantage dans la cybersécurité pour protéger leurs données et leurs infrastructures critiques. Les pratiques de cybersécurité devront être plus proactives, avec des systèmes de détection précoce et des mesures préventives pour réduire les risques d’attaque. L’automatisation et l’intelligence artificielle joueront un rôle de plus en plus important dans la cybersécurité, en aidant à détecter les menaces plus rapidement et à réagir plus efficacement. La mise en place de systèmes de sécurité adaptatifs et dynamiques sera également essentielle pour faire face aux nouvelles menaces qui émergent constamment.

En outre, la cybersécurité devra également tenir compte de l’évolution des technologies émergentes telles que l’intelligence artificielle, la blockchain et les objets connectés, qui présentent des risques de sécurité potentiels. Il sera donc important d’adopter une approche holistique de la cybersécurité, qui englobe la gouvernance, la gestion des risques et la conformité, ainsi que des stratégies de défense des données. Enfin, la sensibilisation et la formation à la cybersécurité devront être renforcées pour aider les utilisateurs à se protéger contre les menaces en constante évolution.

Les deux domaines impliquant les moyens humains nécessitent une amélioration continue et constante :

Le premier concerne la sensibilisation des utilisateurs aux risques liés à la cybersécurité, impliquant notamment la gestion des mots de passe et l’implémentation d’une authentification à deux facteurs (2-FA). Il est également crucial d’accompagner les utilisateurs dans la prévention des attaques de phishing et d’escroquerie en ligne, en les avertissant contre l’ouverture de courriers électroniques suspects ou frauduleux, en mettant en place par exemple une signature électronique préenregistrée en bas de chaque email envoyé.

Le second concerne la gestion des ressources et des compétences en matière de cybersécurité au sein de l’entreprise, y compris l’allocation de budget pour la sécurité[5], la communication et le leadership de la direction, qui doivent être en adéquation avec l’évolution des menaces.

Merci à Alexandrine pour cet article. La sécurité est l’une des 8 facettes de la qualité logicielle définies par la norme ISO 25010, et elle occupe dans ce puzzle une place très particulière en ce qu’elle se prémunit contre des risques changeants, souvent difficiles à anticiper, et qui se trouvent entre les mains de personnes tierces malveillantes. Pour en savoir plus sur ce sujet, nous vous invitons à redécouvrir les articles que nous avons publiés précédemment sur le sujet :

• Quelques éléments de documentation sur la sécurité informatique
• Des bonnes pratiques de sécurité informatique
• Des outils à mettre en œuvre pour consolider la sécurité d’un applicatif ou d’un système
• Autres éléments pour aller plus loin

Sources

[1] https://www.lemondeinformatique.fr/actualites/lire-cyberextorsion-contre-altran-un-cout-estime-a-20-meteuro-74492.html

[2] Dominique Cerruti Dirigeant d’Altran

[3] https://www.zdnet.fr/actualites/ransomware-dominique-cerutti-pdg-d-altran-mon-1er-conseil-assurez-vous-39895949.htm

[4] Merlin NGOUAGNA, Auditeur Cybersécurité, Expert en automatisation, Formation – Acceis

[5] http://www.senat.fr/rap/r20-678/r20-678_mono.html#toc76

Cette année 2023, la plateforme de crowdtesting Testeum, dont Hightest a posé les fondations, offre une campagne par mois à un projet calédonien innovant !

Vous trouverez dans cet article le témoignage des porteurs du premier projet ayant utilisé Testeum dans ce cadre, à savoir l’application Domaine NC.

Qui êtes-vous ?

Nous sommes Adrien Sales, product manager de l’application mobile et de l’API de domaine.nc, et Laurent Schaeffer, développeur de l’application mobile Domaine NC Mobile.

A quoi sert l’appli Domaine NC ?

LS : Pour faire simple, cette application sert à consulter de manière mobile et très compacte les noms de domaines de Nouvelle-Calédonie. Cela permet de visualiser les différentes informations d’un nom de domaine et de recevoir des notifications en cas de d’expiration prochaine de celui-ci.

AS : Nous avons produit une expérience utilisateur disruptive pour faciliter une gestion qui auparavant était plutôt faite à la main… avec des risques d’oubli. Lequel a un impact important sur notre business digital car si votre nom de domaine expire, vous disparaissez du web et donc vous perdez de la visibilité, ou pire : des transactions. Nous voulions mettre en avant la valeur de ces données et leur potentiel.

Quels sont les risques qualité de cet applicatif ? Qu’est-ce qui pourrait « mal tourner » ?

AS : Un des risques est d’avoir une UX non optimale/trop compliquée. On redoutait aussi d’avoir de mauvais temps de réponse… ou pire : pas réponse (une vilaine 500 par exemple) !

A quelles questions vouliez-vous que la campagne de crowdtesting réponde ?

LS : Il fallait s’assurer que chaque utilisateur puisse accéder facilement aux informations qui l’intéressent.

AS : Effectivement, nous voulions nous assurer de la facilité de prise en main par un néophyte. Nous voulions aussi savoir si nos performances étaient passables, bonnes ou excellentes (nous visions une recherche et un affichage instantanés).

Comment avez-vous organisé vos campagnes de test ?

AS : On a d’abord figé un périmètre très réduit de fonctionnalités (notre MVP) via une milestone dédiée sur GitHub, puis on a organisé une première campagne très simple pour récupérer des feedbacks des testeurs sur un jeu très restreint de features.

LS : Suite aux corrections opérées en sortie de cette première session de test, on a lancé d’autres campagnes : une par fonctionnalité.

Qu’avez-vous pensé des retours des crowdtesters ?

LS : Nous avons découvert un point de vue différent du nôtre, qui nous a permis d’améliorer l’application sur un plan UX et fonctionnel.

AS : On a découvert des scénarios de test très pertinents. Par exemple, une personne a cherché la taille maximale acceptée par notre champ de saisie de nom de domaine. Certains tests nous ont même permis d’améliorer la sécurité de notre API ! Nous avons eu de nouvelles idées de simplification d’usage, par exemple l’ajout de placeholders guidant davantage les utilisateurs.

Nous avons aussi eu un retour sur un bug bête et méchant : la recherche automatique ne devait se déclencher qu’à partir de 3 caractères saisis, mais ce n’était pas le cas. Nous avons donc amélioré au passage la vitesse de l’appli et réduit le nombre d’appels de l’API.

Qu’avez-vous pensé de la plateforme elle-même ?

AS : Les dashboards sont beaux et très faciles à exploiter ! Tout est prêt à l’emploi. On a pu les copier-coller tels quels pour organiser notre travail en équipe, avec très peu d’efforts.

LS : La plateforme est facile d’utilisation et permet de bien organiser ses campagnes de manière optimale.

Pour vous, comment une démarche crowdtesting devrait s’articuler avec les autres pratiques de test ?

AS : De ce que j’ai pu en voir, je trouve que cela arrive par exemple pour tester des RC (release candidates) ou des bêtas, et en conditions réelles (sur une infra cible).  J’ai par exemple pu mesurer l’impact sur les perfs de l’API et voir si toute la chaîne tenait bien le coup : c’était vraiment de bout en bout ! Génial et terriblement efficace.

Je verrai bien une description d’organisation, qui intégrerait le crowdtesting avec toutes les autres phases de test et la partie release planning.

Je pense que left-shifter une campagne ferait sens dans une approche LEAN, ce qui privilégierait le Time To Market, la qualité et plus généralement toute la chaîne de delivery. Nous avons implémenté une chaîne de CI complète qui nous permettait de déployer avec une simple release la version sur les stores… et de manière sémantique. Ainsi on peut se concentrer sur des périmètres compacts et boucler très rapidement et avec une grande qualité logicielle. Nous avons tout fait via des outils cloud GitHub/Fastlane.

Quel conseil donneriez-vous à une personne qui envisagerait une démarche de crowdtesting pour tester son produit ?

AS : Je lui conseillerais de :

1. Sensibiliser son équipe : lui présenter les concepts clés de la plateforme à son équipe et de la sensibiliser au Left-Shifting. Lui montrer des exemples de campagnes : les wins, les fails, des exemples très concrets, présenter les approches (une grosse campagne de test VS plusieurs petites) voire diffuser des témoignages.
2. Sensibiliser sur le fait que le test d’une feature fait parties des coûts de dev… et que donc cela doit être pris en compte dès le début.
3. Au moment de la conception de la campagne de test, proposer un parcours complet pour profiter au mieux de la plateforme (ROI)
4. Disposer impérativement d’un PO (et donc d’une vision produit très claire)
5. Embarquer l’équipe (Devs, Scrum Master) afin que le crowdtesting soit une phase projet comme une autre… et si possible des newbies complets à l’équipe qui ne connaissent rien au domaine métier.
6. En bonus : créer un club d’utilisateurs qui ont utilisé la plateforme et qui pourraient créer un guide de best practices.

Tiens, c’est quoi qui brille par terre ? Une lampe ? HA, voici le génie de Testeum, vous pouvez faire 3 voeux de nouvelles fonctionnalités sur la plateforme !

LS : On en a 3 chacun ? J’en fais 2 pour ma part : 1) La possibilité d’exporter les données de test vers d’autres platformes (style GitHub ou autre) ou au format JSON, et 2) Fournir une API pour récupérer les données de test et/ou d’autre données.

AS : J’en fais 3 ! 1) Pouvoir trigger des Webhooks pour pousser les retours directement en issues (Github) ou déclencher des workflows (IFTTT, Zapier, Power Automate, …), en mode événementiel, ou à des chaînes de CI. 2) Fournir une API pour consommer les données des feedbacks et des campagnes à des fins d’intégration B2B ou de reporting. 3) Pouvoir targetter des profils professionnels (en plus des critères actuels : âge, sexe, pays et type de matériel possédé).

Merci à Adrien et Laurent pour ce témoignage ! Pour en savoir davantage sur la génèse de leur projet, vous pouvez visionner cette vidéo.

Vous pouvez également consulter deux de leurs rapports de test Testeum : celui-ci et celui-là !

Pour bien démarrer 2023, nous vous proposons un bouquet de méthodes et bonnes pratiques ! Objectif : booster à la fois votre productivité et votre bien-être au travail. Ces astuces, applicables dans tout métier de l’IT, ont été collectées auprès de nos collaborateurs, et auprès de ceux de partenaires en Nouvelle-Calédonie. C’est donc l’occasion aussi de vous faire connaître quelques visages du monde numérique calédonien !

Gestion du temps, efficacité, montée en compétence… Vous trouverez certainement au moins une bonne idée actionnable dans votre quotidien tout au long de cet article !

Bonne lecture et meilleurs vœux pour 2023 !

1) Maîtriser son temps avec la technique Pomodoro

Pomodoro, qu’est-ce que c’est ?

Clément Flavigny, team leader chez Atlas Management, utilise fréquemment la technique du Pomodoro, qui consiste à travailler sur des périodes chronométrées de 25 minutes séparées par des pauses de 5 minutes. Cette technique a été inventée à la fin des années 1980 par le consultant Francesco Cirillo.

Voici comment Clément s’organise concrètement :

La veille, je classe mes tâches du lendemain des plus importantes aux moins importantes et les programme par créneau. J’entame 25 minutes sur la tâche la plus importante et je mets mon téléphone portable hors de ma vue si besoin. Je consulte mon téléphone et me lève pour dégourdir mes jambes sur les 5 minutes de pause.

Il utilise cette méthode quand il a le temps de classer ses tâches la veille ou le matin même, quand il a des priorités établies, et/ou quand il a plusieurs sujets, missions ou clients.

Ce que ça lui apporte ?

• Arriver le matin avec de la confiance dans le programme de la journée
• Savoir que je vais avoir un temps de pause quoi qu’il arrive
• Être capable à la fin de la journée de savoir si j’ai été productif

Cette méthode n’est pas forcément simple ou rapide à adopter. Clément a mis un an à l’intégrer dans son rythme de travail. Il lui arrive de ne pas utiliser la technique du Pomodoro, en particulier quand je n’ai pas classé mes tâches ; quand je suis en réunion toute la journée, quand je suis en retard.

Il conseille cette pratique aux personnes qui travaillent sur plusieurs tâches ou plusieurs projets, qui se dispersent parfois dans leurs tâches et ont l’impression de n’avancer sur rien.

Pomodoro en pratique

Ses quelques astuces pour les personnes qui voudraient se prêter à l’exercice :

• Utiliser un minuteur avec une alarme
• Commencer à essayer lors du télétravail car c’est plus facile d’avoir son alarme que dans l’open space
• Ne pas hésiter à ignorer les mails entrants durant 25 minutes
• Dire aux collègues qui ont une question d’attendre la fin de la plage horaire de 25 minutes de travail.

Vincent Lavergne, UX designer chez Tealforge, utilise aussi cette technique. Quand je ne suis pas dans le stress, ça marche assez bien, surtout dans la création où s’acharner ne fonctionne pas.

2) Zapper l’étape « brouillon »

Laurence Marchois, facilitatrice opérationnelle et consultante chez Atlas Management, partage une astuce qui lui permet de gagner beaucoup de temps lors de la rédaction de documents.

Toujours avoir en tête quel livrable final on doit réaliser (CR, étude, etc.) et le créer directement sans passer par des documents intermédiaires. Ca permet de cibler directement les informations qui apportent vraiment de la valeur, et gagner du temps de remise en forme.

3) S’inspirer de Scrum (même en solo !)

Ryan Julia, consultant junior chez Atlas Management, s’inspire de la méthode Scrum au quotidien.

Ses sprints durent une semaine et incluent un planning, une revue et une rétro qui ont lieu chaque lundi matin. Lors de cette session, il définit un objectif pour la semaine.

Tous les jours, il procède à un daily. Il y fait le point sur les obstacles et les choses à faire dans la journée.

Il tient à jour un backlog catégorisé et priorisé avec des sujets captés au vol ou encore en attente pour les prochains sprints. Ce backlog mélange les sujets pro et perso.

Cette revue hebdo, je la tire de la méthode GTD (Getting Things Done), un bouquin de productivité. Ca ne convient pas à tout le monde car ça peut paraître « trop cadré pour pas grand chose », mais moi ça m’aide bien.

Autre outil que Ryan utilise : toggl, pour savoir où va son temps, ajuster ses efforts en planning hebdo ou en daily, et évaluer les moments de la semaine ou de la journée où il est le plus productif, afin d’y positionner ses dossiers les plus importants.

4) Lister ses tâches aux petits oignons

Le double avantage de la todo-list

Tenir une todo-list est une astuce qui revient souvent. C’est à la fois bon pour la productivité, et bon pour le moral ! Elodie Luz, consultante experte chez Atlas Management, utilise cette pratique pour s’alléger l’esprit et pour la satisfaction de rayer quand on a fini quelque chose ! Je me sers d’un bon vieux cahier qui me permet au passage de faire une pause d’écran quand je retravaille cette liste ou que je raye au fur et à mesure les tâches réalisées. En complément lorsque je sais qu’une des tâches doit prendre un certain temps de concentration et donc sans être dérangée, je me sers de mon agenda pour bloquer des créneaux sur ces actions.

La todo-list Monday d’Antoinette

Antoinette Dubroeucq, consultante cohésion et marque employeur chez Ahonei, plussoie : Ça améliore à la fois ma productivité car ça me rend plus efficace, et mon bien-être car je suis moins stressée d’oublier des choses et j’anticipe ma charge de travail.

Elle note l’ensemble des choses à faire sur la même liste. Elle la parcourt au début de la journée afin de se faire un rappel des tâches qui l’attendent, et la remet à jour à la fin de la journée avec les nouvelles échéances et les évolutions.

Ça m’apporte plus d’efficacité car je n’oublie aucune tâche. Ma productivité est doublée car je ne perds pas de temps à me demander quoi faire aujourd’hui, quelles sont les priorités, ni à me rappeler où en est tel sujet. Tout est déjà écrit. Je me sens également moins stressée car j’ai un visuel de la charge de travail qui m’attend dans les jours / mois à venir. Je peux donc trier les tâches en fonction de leur deadline, de leur complexité, etc.

Antoinette partage avec nous une todo-list quelle a créée sur Monday :

Mais les todo-list ne se ressemblent pas toutes et doivent être créées en fonction du besoin de chaque personne.

Le dashboard Notion de Loic

Loic Hamouda, consultant senior en transformation digitale chez Atlas Management, utilise quant à lui le logiciel Notion pour lister ses tâches.

Je crée des tâches auxquelles j’ajoute des tags (personne à contacter, client pro, perso,…), des deadlines et des points d’avancement.

Il ne lui a fallu que quelques jours pour adopter cet outil, à l’issue d’une formation en ligne gratuite.

Son conseil ? Essayer de réaliser son premier dashboard/template par soi-même. Il est possible aussi de récupérer ceux que les autres utilisateurs mettent à disposition (il y a une très grande communauté).

Voici à quoi ressemble son dashboard :

La todo-list quotidienne de Zoé

Zoé Thivet, spécialiste en test logiciel chez Hightest, utilise quant à elle un rudimentaire fichier txt : un fichier par jour. La granularité est assez fine (entre 50 et 100 tâches par jour).

Le bloc du haut contient les tâches réalisées, et le bloc du bas, les tâches à faire.

Dès qu’une nouvelle idée arrive, une ligne est ajoutée dans le bloc du bas. Elle est positionnée plus ou moins haut parmi les lignes déjà existantes en fonction des priorités. Dès qu’une tâche est terminée, elle est déplacée dans le bloc du haut.

Tout au long de la journée, mon attention se focalise entièrement sur la ligne où apparaît la flèche rouge. Autant que possible, je ferme tous les onglets et toutes les applications inutiles à cette tâche. Même si « je pourrais en avoir besoin plus tard » !

En fin de journée, je réorganise le bloc du bas, et les tâches du lendemain sont prêtes. J’utilise ça en complément de mon calendrier.

5) Bloquer des créneaux de travail à l’avance

Cindy Da Silva, chargée de communication/marketing chez Tealforge, programme chaque semaine à l’avance pour s’assurer de produire à temps les livrables demandés. Je prends l’ensemble de mes clients et la liste des livrables à réaliser sur le mois (voire plus). Je fixe un maximum à l’avance les créneaux pour les réaliser et faire le travail attendu. Sans oublier de laisser des moments « libres » pour les éventuelles réunions ou imprévus.

Bastien Serafin, consultant marketing chez Tealforge, utilise aussi cette pratique. J’utilise la technique du time blocking depuis plusieurs années. L’idée est de bloquer mon agenda sur des tâches et de ne faire que ça à ce moment là. Par exemple, je consulte et traite mes mails en début et fin de matinée et en début et fin d’après-midi.

6) L’art de vivre à la Florian

Florian Michaud, ingénieur QA chez Hightest, dévoile à son tour ses astuces avec les bonnes vibes qui le caractérisent !

Je vais te donner mes quelques tips qui font de moi el maestro de los consultantes :
1- La classique todo-list sur le bloc-notes, pas de superflu on est tranquille
2- Je connecte mon ordinateur ou celui du client à Spotify ou YouTube pour éviter, si je veux mettre de la musique, de devoir sortir mon téléphone et me distraire en consultant mes mails
3- Une pause toutes les deux heures, comme sur l’autoroute
4- Si vraiment je n’arrive plus à me concentrer, je fais une coupure de 5 minutes. Je regarde les infos calédoniennes ou les billets d’avion, ça permet une pause à l’esprit
5- Je mange des pommes en travaillant, ça me permet de me concentrer
6- Boire de l’eau est mon meilleur conseil

7) Faire de la veille avec Feedly

Yann Levy, tech lead chez Tealforge, mène une veille quotidienne qui lui permet de rester à la pointe de ses sujets d’expertise. Pour ce faire, il utilise au quotidien Feedly, un agrégateur de flux RSS.
Concrètement, dès que je trouve une source qui m’intéresse, notamment sur la tech, je la rajoute à mon flux Feedly. Tous les jours je peux voir les trending topics sur les nouvelles technos, des nouvelles manières de s’organiser, de nouveaux plugins, etc. Je l’utilise tous les matins en arrivant au bureau. Je parcours tous les titres, sélectionne ce qui m’intéresse et pousse un peu plus ma recherche dessus. C’est comme les échecs, on comprend son fonctionnement très rapidement mais on met du temps avant de correctement s’en servir ! Un peu #oldschool comme méthode, mais je ne m’en séparerais plus.

Cette pratique permet de centraliser dans un même lieu un grand nombre de sources. Elle épargne donc le travail fastidieux d’ouvrir tous les matins un grand nombre de sites différents.

A vous de jouer !

Et vous, quelles sont les astuces productivité et bien-être qui vous aident au quotidien ? Partagez-les avec nous en commentaire !

MAJ du 24/07/2023 : Attention, le site ISTQB Online mentionné dans cet article ne semble plus actif. Nous remercions toutefois les personnes à l’origine de cette initiative, espérant que le site reverra le jour prochainement !

Précédemment, nous avons publié des articles permettant de guider de nouveaux aspirants testeurs :

• Comment devenir testeur logiciel ?
• 4 clés pour réussir son premier entretien d’embauche de testeur
• Petites histoires de reconversion dans le test logiciel

Aujourd’hui, dans cette lignée d’articles, nous avons le plaisir de mettre en avant une initiative très utile menée par deux testeurs. Il s’agit du site istqb.online, créé par Med Aziz Zouaoui et Sarah Sliti, et qui contient des quiz blancs pour réviser les certifications ISTQB. Nous apprécions et partageons cet esprit de partage et de challenge, ayant nous-mêmes quelques quiz blancs à notre actif. C’est donc avec joie que nous échangeons aujourd’hui avec Med Aziz et Sarah !

Hightest : Bonjour à vous deux ! Et tout d’abord, merci pour cette belle initiative. Comment vous est venue l’idée ?

Med Aziz Zouaoui : Tout d’abord je voudrais vous remercier pour votre interview et pour l’aide que vous allez apporter à plein de gens en faisons connaître notre site web.

Je suis un développeur qui a décidé de se lancer dans le métier de test et qui avec l’aide de Sarah, y est arrivé. C’est durant ma reconversion que Sarah et moi-même avons eu l’idée de créer un site web qui serai 100 % éducatif, à but non lucratif, dans lequel tout le monde pourrait s’autoévaluer et s’entraîner avant de passer la certification ISTQB.

Hightest : Comment avez-vous découvert le métier de testeur ?

Med Aziz : Après avoir été un marketer et un développeur CMS, j’ai découvert le métier de test à travers Sarah, et après des séances de partage de connaissance et de coaching je me suis senti dans mon élément et j’ai tout de suite décidé d’intégrer le monde de testing.

Sarah Sliti :  J’ai effectué mon projet de fin d’étude au sein d’un département de software testing. Pendant que je travaillais sur mon projet, on m’a demandé de venir en renfort à une équipe de test pour respecter un délai de livraison pour un client important et depuis j’ai développé une passion pour ce domaine et j’ai décidé d’en faire ma carrière.

Hightest : Que vous ont apporté les certifications ISTQB lors de votre itinéraire de QA ?

Med Aziz : Puisque je n’étais pas un testeur de formation, le monde du testing était inconnu pour moi, mais grâce aux certifications ISTQB j’ai pu affiner mes connaissances et avoir les compétences requises pour exceller dans mon travail.

Sarah :  Les certifications ISTQB m’ont apportée beaucoup de connaissances à propos du software testing. Elles ont mis une structure aux notions que j’ai pu acquérir durant ma carrière. Ces certifications m’ont permis de comprendre les grandes lignes du métier de test ainsi que les détails du processus du test et comment l’intégrer dans le cycle de vie logiciel.

Hightest : Qu’est-ce qui vous plaît le plus dans le métier du test ?

Med Aziz : La fierté de savoir que la place d’un testeur est devenue primordiale au sein d’une entreprise

Sarah : Satisfaire le besoin du client et contribuer à la bonne qualité du produit et au succès du projet.

Hightest : Tous les testeurs sont différents et chacun a son propre « style » de test. De votre côté, comment vous décririez-vous en tant que testeurs ?

Med Aziz : Je suis un testeur méticuleux qui éprouve un plaisir en chassant les bugs.

Sarah : Je suis une testeuse curieuse qui a l’œil pour le détail, organisée dans ses idées avec une bonne capacité d’analyse.

Hightest : Quelles sont les nouveautés que vous prévoyez pour votre site ?

Med Aziz & Sarah :  Intégrer un forum pour plus d’interactivité avec les passionnés de test, partager des idées et bénéficier des expériences des autres.

Hightest : Recherchez-vous des contributeurs pour créer de nouveaux quiz ISTQB et étoffer votre site ?

Med Aziz & Sarah : Nous sommes ouverts à toutes contributions. Vous pouvez nous envoyer vos idées à travers notre site, nous avons ajouté une rubrique pour cela. Nous pourrons discuter et voir ce que nous pourrons faire pour encore mieux aider la communauté du test.

N’hésitez donc pas à visiter istqb.online ! A ce jour, il propose déjà 6 quiz blancs pour s’entraîner à la certification de niveau Fondation.

Merci à Med Aziz et Sarah pour leurs réponses !

Crédit image de couverture : cottonbro

Dans notre précédent article, nous partagions quelques astuces pour réussir son premier entretien d’embauche en tant que testeur, et nous invitions à mettre en avant les expériences passées dans d’autres domaines. Aujourd’hui, nous avons le plaisir d’approfondir ce sujet, en partageant avec vous un beau bouquet de témoignages recueillis auprès d’une multitude de QA issus de reconversions. Et vous verrez que beaucoup de ces profils ont exercé dans des domaines très éloignés de l’informatique, et ont su tirer parti au maximum de ces expériences !

Les soft skills sont au cœur de cet article, et nous espérons qu’à votre tour vous prendrez conscience des trésors que vous apportent vos expériences passées.

Bonne lecture, et bon courage aux aspirants testeurs qui nous lisent et se préparent à leur nouvelle carrière !

Sommaire

1. De l’équipe de foot à l’équipe de test, avec Romain C
2. Reconversions jumelles, avec A.B
3. Des tests chimiques aux tests logiciels, avec Sabri Taleb
4. Luxe, test et qualité, avec Coralie Cebron de Lisle
5. De la QSE à la QL, avec F.D
6. Exigence et qualité : de commerçant à testeur, avec David Venjon
7. En mode test, avec Marion Lemaire
8. De maître de conf’ à maître Scrum, avec Munaf Abbas
9. Les savoureuses recettes de Julien Antonio
10. Du parc d’attractions à l’attraction pour la qualité, avec Naa’ilah Aly
11. Téléopérateur : l’envers du décor, avec Alvine Kamga
12. Record & Playback, les enseignements de la production musicale, avec Dino Dona
13. Le test est le remède, avec Sonia Boutaraamt
14. Fuel for test, avec Nabil Boulehrouz
15. Orchestrer la lumière et les tests, avec Sylvain Viole

De l’équipe de foot à l’équipe de test

Ce témoignage de Romain C file la métaphore du football, son premier domaine d’expertise, et qui vient aujourd’hui nourrir sa pratique du test. L’état d’esprit qui en ressort est extrêmement motivant… voire épique !

J’ai pu travailler 2-3 ans dans le secteur du sport avant de prendre un virage à 90° pour travailler dans le monde du test.

Mes premières expériences dans le sport me servent beaucoup aujourd’hui dans le monde du test.

Dans le sport j’utilise :

• la persévérance
• la rigueur
• l’abnégation
• l’esprit d’équipe
• la remise en question
• le dépassement de ses limites
• l’esprit de compétition

Ces éléments me servent à surmonter les difficultés de projets ou des équipes et je n’aime pas abandonner ou perdre. 😉

Je fais beaucoup de métaphores et d’allusions au sport.

Je considère vraiment ma squad comme mon équipe de foot avec :

• ses points forts
• ses points faibles
• ses individualités fortes
• les travailleurs de fond
• les leaders
• les suiveurs
• les relayeurs

Aussi, je considère :

• L’Engineering Manager comme le coach
• Le QA Engineer comme le milieu soupape, sentinelle
• Le produit PM/PO comme le créateur de jeu (milieu offensif, attaquant)
• Les devs comme des attaquants ou des défenseurs selon leur profil
• Le sponsor métier comme le gardien de but.

⚽

Reconversions jumelles

Dans ce témoignage, A.B illustre ce qui pourrait être un proverbe : “tous les chemins mènent au test” ! Elle montre aussi l’intérêt d’avoir pu développer une expertise métier poussée dans un domaine particulier.

A la base, je suis ingénieur en biologie cellulaire et moléculaire, mais il n’y avait pas du tout de débouchés.

Ma jumelle, qui avait fait une école de commerce et est devenue QA, m’a cooptée. 

On a toutes les deux fait des études qui n’ont rien à voir et on se retrouve à faire le même métier !

J’ai fait pas mal de QA dans le domaine médical. Je me mettais à la place du personnel de santé et surtout, je comprenais à quoi servaient les features implémentées.

Il y a aussi beaucoup de logique. Des symptômes qui indiquent un diagnostic et entraînent un traitement. Le traitement a potentiellement des effets secondaires, est-ce que c’est acceptable ou non… ça s’applique aussi à l’informatique.

Maintenant que je ne travaille plus dans le médical, je garde le même esprit de bien comprendre la feature et la même logique. Et je trouve ça hyper cool d’avoir des résultats si rapides (contrairement à un traitement qui nécessite des jours et des jours avant d’avoir un résultat). En une ligne de code, ça peut être résolu 😊

👩👩

Des tests chimiques aux tests logiciels

Sabri Taleb est chimiste de formation et a même réalisé un doctorat dans cette discipline. Dans sa carrière de testeur, il a pu constater des parallèles entre les deux univers. 

La chimie est un domaine passionnant mais parfois surprenant. Il faut être extrêmement rigoureux, curieux et avoir un esprit critique (comme dans le test), contrôler chaque étape de transformation en faisant des analyses qualité (très souvent plusieurs analyses qui viennent compléter ou confirmer que le produit attendu est bien formé) et si nous voyons que ce n’est pas le cas, analyser et comprendre ce qu’il s’est passé et essayer de reproduire l’anomalie (si c’en est une) et modifier les protocoles.

Et même si le protocole est maîtrisé et routinier, un contrôle n’est pas exclu (encore une fois, comme dans le test 🙂 ), même si nous n’allons pas pousser les analyses qualité (une analyse rapide suffit).

De tout ça, il y a beaucoup de similitudes, ce qui fait que j’ai pu me sentir à l’aise dans cette nouvelle aventure. 

En effet, Sabri Taleb s’est retrouvé propulsé dans le monde du test (comme tant d’entre nous !) par une heureuse opportunité… qu’il a saisie in extremis !

J’ai toujours été attiré par ce que je ne connaissais pas. Lors de ma thèse, on m’avait proposé de refondre un site web, j’ai accepté sans avoir aucune connaissance, du coup j’ai aimé rechercher des solutions et tâtonner jusqu’à avoir un site fonctionnel en y ajoutant une fonction qui permettait aux étudiants de s’inscrire en master directement en ligne. Fini les dossiers papier !

C’est un concours de circonstances ; mes expériences professionnelles dans la chimie étaient courtes (CDD) et il n’y avait pas de postes dans ce domaine dans ma région. Privilégiant le côté familial, j’ai donc regardé ce qu’il y avait de disponible dans les environs, et j’ai constaté qu’il y avait des postes principalement de l’informatique.

J’ai trouvé une annonce qui offrait une possibilité de reconversion de bac +5 scientifique en dev Java, j’ai postulé et j’ai été accepté de suite en POEI (une entreprise s’engageait à embaucher après la formation).

A la fin des 3 mois intenses où on apprend la base du développement et des langages, l’entreprise m’a proposé de suivre une autre formation de 3 mois pour faire de la QA.

J’ai d’abord refusé, puis j’ai accepté de suivre la formation le jour de la date de clôture des dossiers.

Et c’est comme ça que je suis devenu QA avec des compétences en automatisation.

⚗️

Luxe, test et qualité

Avant de se reconvertir dans le domaine de la qualité logicielle, Coralie Cebron de Lisle a exercé dans différents domaines, dont la vente de produits de luxe. Ce qui a contribué à forger son exigence qualité.

En tant que vendeuse de produits de luxe, j’ai appris que les petits détails ont une grande importance et c’est dans son ensemble que le produit prend de la valeur, car aucun détail ne doit être négligé. Et c’est bien là qu’on peut reconnaître la qualité d’un produit.

Tout comme dans le test, il est important d’être curieux, à la fois des technologies utilisées et de la façon de travailler de ses propres collègues afin de comprendre comment le résultat final est obtenu.

Ses expériences précédentes ont également eu un impact positif sur son savoir-être : 

Dans mon expérience passée, que ce soit dans le tourisme, ou dans le commerce, être un bon communicant est essentiel au sein de l’équipe, non seulement par la bonne humeur, mais aussi par une facilité d’adaptation à travailler avec des collègues avec des personnalités très différentes.

⌚✨

De la QSE à la QL

Dans ce témoignage, F.D met en évidence les atouts qu’apporte un background QSE à une carrière dans la qualité logicielle.

En tant qu’ingénieur QSE, j’étais chargée d’accompagner les entreprises dans leurs démarches de certification ISO/TS 14001. Ça consistait à mettre en place la gestion des déchets, la gestion des produits chimiques ou encore la veille réglementaire pour la partie environnement. Pour la qualité, les activités étaient du type audit, reporting fournisseur.

Je dirais que les parallèles les plus évidents avec le test logiciel sont surtout du côté qualité. Pour l’écriture des rapports d’anomalies, je m’inspire beaucoup des méthodes de résolution de problèmes : la méthode QQOQCP, les 5 pourquoi, entre autres méthodes… Cela m’aide beaucoup à structurer ma pensée.

Le côté très procédural des certifications ISO m’a aussi permis d’acquérir des compétences en gestion documentaire. Cela n’est pas forcément mis en avant dans le contexte agile mais chez une entreprise cliente qui ne possède pas d’outils de tests, ça peut être un sacré avantage.

Le métier d’ingénieur QSE est aussi un métier de formateur (aux procédures qualité, aux situations d’urgence…) Il m’a permis aussi de savoir comment m’adresser à différents publics (développeurs, product leaders, etc…) pour aller chercher l’information, pour rendre compte d’une anomalie, pour décaler un planning…

📃✅

Exigence et qualité : de commerçant à testeur

Dans son “ancienne vie”, David Venjon était chef de secteur alimentaire. Ce métier consiste à gérer le secteur alimentaire d’un magasin en incarnant les valeurs et l’esprit de l’enseigne.

Dans ce métier, rechercher en permanence la satisfaction des clients est primordial. Il faut avoir le sens du commerce et de la bienveillance. On doit veiller au respect de la politique commerciale du groupe, de la mise en place de l’ensemble des opérations commerciales. Avoir des connaissances en gestion est un plus. Il faut connaître ses budgets, apporter des correctifs si nécessaire et bien entendu, développer son CA. On doit former ses collaborateurs, les faire monter en compétence, recruter le cas échéant. Des notions de droit du travail sont nécessaires, et la rigueur et l’anticipation font partie du quotidien.

Lors de ma reconversion professionnelle dans la qualité logicielle, j’ai analysé mes softs et hard skills acquises tout au long de ma carrière (17 ans) et j’ai synthétisé celles qui me seraient utiles dans l’informatique.

Je retiens les compétences transverses suivantes :

• analyse ;
• organisation ;
• rigueur ;
• adaptabilité ;
• diplomatie ;
• écoute ;
• initiative.

Toutes mes compétences étaient axées vers un seul et même objectif : la satisfaction du client.

Depuis 2 ans, je me suis appuyé sur ces forces, qui représentaient mon socle de base, mon cercle de confort, afin de pouvoir me dépasser et acquérir de nouvelles compétences déterminantes dans mon nouveau métier :

• l’investigation ;
• l’autonomie (encore plus prononcée que dans mon ancien métier) ;
• l’apprentissage (dans une démarche intellectuelle et non mécanique) ;
• la réflexion ;
• le dépassement de soi.

Les compétences transverses sont une valeur refuge sur lesquelles je m’appuie et je me réfugie en cas de difficulté pour mieux rebondir ensuite.

Cela me rend encore plus exigeant et consciencieux dans mon quotidien, ce qui m’a très vite rendu crédible au sein de mon équipe et m’a donc donné de la confiance en moi.

🤝

En mode test

Marion Lemaire a débuté sa carrière en tant qu’ingénieur textile spécialisée en mode éthique ; elle faisait également du stylisme photo et du conseil. Elle a constaté, elle aussi, des ponts entre ces différentes disciplines et le test logiciel.

Il y a évidemment la minutie de l’ingénierie et l’habitude des process, mais au-delà de ça, il y a plusieurs choses :

• l’aptitude à comprendre un besoin client même quand le client ne sait pas exprimer ce qu’il veut (classique)
• la facilité à appréhender différents secteurs et à s’intégrer dans une équipe existante
• l’évident sens du détail
• la capacité à se mettre dans les chaussures de l’utilisateur final, car dans tout métier on est confronté à l’outil IT (logiciel de modélisation, plate-forme de vente en ligne, etc)
• l’aptitude à comprendre des règles de gestion complexes (j’accompagnais les démarches d’audit vers la labellisation écologique par exemple)
• la facilité à être un couteau suisse et un interlocuteur privilégié de toutes les parties prenantes
• les capacités de communication et de restitution de l’information (j’étais gestionnaire de la fédération des acteurs de la mode éthique)
• les capacités d’organisation (gérer un shooting de A à Z, c’est pas de la tarte)
• le rédactionnel (je faisais des piges pour des magazines de mode)

Suite à cela, Marion a suivi une formation à l’EQL (Ecole de la Qualité Logicielle, à Montrouge juste à côté du Beffroi où se tient tous les ans la JFTL). Elle y est ensuite restée en tant que formatrice puis encore recruteuse de profils.

J’ai vu des artistes tatoueurs devenir d’excellents testeurs techniques, des prothésistes ongulaires devenir de géniales fonctionnelles avec un super côté support, et pléthore de profils incroyables comme des scripts dans le cinéma, des thésards en histoire de l’art, des artistes en mosaïque, des astrophysiciens… C’est incroyable les ponts que l’on peut faire !

📸

De maître de conf’ à maître Scrum

Munaf Abbas, ancien enseignant-chercheur, met en lumière par son témoignage de nombreux mécanismes de l’exigence intellectuelle, nécessaire à de bons tests.

Je suis un ancien enseignant-chercheur ayant travaillé pendant quelques années dans l’enseignement supérieur en France et à l’étranger. J’avais un poste fixe à l’étranger, Maître de conférences, que j’ai quitté pour revenir en France, où les postes sont très rares et parfois inaccessibles. J’ai deux doctorats, l’un en linguistique appliquée à la traduction et l’autre en sciences de l’information et de la communication.

Quand je me suis reconverti à l’informatique, ce qui m’a le plus attiré étaient la méthode et la qualité (la deuxième étant en partie une conséquence de la première).

Il y a beaucoup d’éléments que j’ai pu facilement recontextualiser de mes expériences passées : la méthodologie, la rigueur, la planification et le travail en amont sur la conception et sur les échéances. L’évaluation également est toujours présente à l’esprit ; comment on pourrait évaluer les choses, individuellement et collectivement : un produit, un plan ou un process de réalisation. La vision micro du projet se marie ainsi à la vision macro, et jouer un rôle de connecteur par moment m’a bien plu. J’étais, jusqu’à ma précédente mission, Scrum master et testeur en même temps, et mon expérience précédente m’a bien aidé là-dedans.

👨‍🏫

Les savoureuses recettes de Julien Antonio

Ancien cuisinier, Julien Antonio a puisé dans son expérience en cuisine de nombreux réflexes utiles en tant que QA.

L’attention au détail et le souci de la qualité sont importants dans les deux cas.

Côté testeur, il y a le fait de vérifier que ça fonctionne bien mais aussi que ça répond au besoin du client, plus les petits à-côtés qui font partie de la qualité. Par exemple : “Pourquoi ce nouveau bouton n’a pas du tout le même comportement que tous les autres sur la même page quand on clique dessus ou quand on le survole ?”

Côté cuisine, je trouve que de bonnes questions à se poser quand on goûte un plat sont : “Est-ce que c’est bon ? Est-ce que j’ai envie d’en reprendre une deuxième cuillère juste par gourmandise ? Si ce n’est pas le cas, qu’est-ce qui manque, quel est le problème ?” Ce n’est souvent pas grand-chose (un peu de jus de citron pour ajouter une touche d’acidité par exemple) mais ça fait la différence entre un plat correct et un plat où on va se dire « Han mais c’est super bon ! »

Côté développement on insiste beaucoup sur :

1. Tester tôt et tout au long du développement
2. La qualité des spécifications.

Côté cuisine on pourrait insister sur :

1. Goûter tôt et tout au long de la préparation
2. La qualité de la rédaction des recettes.

Et ça a beaucoup d’importance :

1. Quand je cuisine avec des proches je les fais souvent goûter régulièrement et se poser la question que j’évoquais plus haut (« Est-ce que c’est bon ? Qu’est-ce qui manque ? »), plutôt que de juste suivre la recette et de ne se poser la question de la réussite du plat qu’une fois que celui-ci est sur la table.
2. Une recette qui dit par exemple « Laisser réduire quelques minutes, jusqu’à obtenir une consistance proche de celle du miel » est plus utile car plus précise qu’une qui dirait juste « Laisser réduire réduire 5 minutes ». Car, pourquoi 5 minutes ? Pourquoi est-ce qu’on laisse réduire en fait ? Qu’est-ce qu’on veut comme résultat ? C’est sans doute clair dans la tête de l’auteur, mais ce n’est pas du tout explicite dans celle de la personne qui lit la recette. On ne peut pas modifier la rédaction d’une recette, on peut juste être plus sélectif quand on feuillette un livre de recettes avant de l’acheter. Et on peut appliquer la même logique quand on retravaille des specs avant de les confier aux devs : qu’est-ce qui nous semble évident mais n’est pas dans le texte ? Est-ce qu’il reste des ambiguïtés ? Etc.

👨‍🍳

Du parc d’attractions à l’attraction pour la qualité

Avant de rejoindre le monde de la qualité logicielle, Naa’ilah Aly a travaillé plusieurs années à Disneyland Paris. Une expérience humaine très riche et stimulante, qui lui permet aujourd’hui de faire face à de nombreuses situations.

J’ai effectué plusieurs postes à Disneyland Paris, le plus significatif ayant été celui de guest flow. Un peu partout à travers le parc nous étions en charge de gérer les différents flux des visiteurs, cela pouvait se traduire aussi bien par informer les gens, répondre à leurs attentes, assurer leur sécurité durant les parades, contrôler l’accès à certaines zones du parc pendant les spectacles mais aussi se charger de l’ouverture de certaines attractions et de l’accueil du public au sein de ces attractions.

La sécurité était la priorité pour Disney et les vérifications essentielles. Je n’aurais pas pu souhaiter une meilleure préparation pour mon métier actuel. J’y ai appris à faire des vérifications méticuleuses, aidées par l’usage de checklists, à ne pas laisser de détails sans surveillance, à faire les choses de façon logique et ordonnée. J’y ai aussi appris à placer le client en priorité, à faire preuve d’empathie, à dépasser ses attentes. J’y ai gagné également une bonne dose de diplomatie et une expérience dans la résolution de conflits.

C’est un peu grâce à Disney que je peux aujourd’hui vérifier une feature avec précision, en me mettant à la place de l’utilisateur et en rapportant les bugs mais toujours avec le sourire !

🎠

Téléopérateur : l’envers du décor, avec Alvine Kamga 

Forte d’une expérience de téléopérateur, Alvine Kamga en tire une compréhension profonde des impacts d’une mauvaise expérience client, ainsi qu’une forte capacité d’écoute et d’empathie.

Mon expérience en tant que téléopérateur m’a permis de comprendre l’importance de la satisfaction du besoin de l’utilisateur final :

• En tant que téléopérateur je me trouvais au premier plan, en contact direct avec l’abonné et je faisais face à l’insatisfaction permanente de ce dernier par rapport au service rendu.
• En tant que testeur je me retrouve de l’autre côté de la barrière et à chaque fois que je travaille j’ai toujours à l’esprit qu’au bout de la chaîne il y a un utilisateur final qui doit être satisfait du service ou du produit qui fait l’objet de mes tests. Ce qui constitue une source de motivation permanente.

Comme je l’ai appris de mon expérience de téléopérateur : “Un utilisateur satisfait est un utilisateur dont le besoin a été compris et résolu.”

🎧

Record & Playback, les enseignements de la production musicale 

Dino Dona a démarré sa carrière dans le monde de la production musicale. Un domaine qui semble éloigné de celui du domaine logiciel, et pourtant, les parallèles sont nombreux entre le processus de création d’un applicatif et celui de la production d’un album.

Lorsque l’on produisait des albums, le rythme était assez semblable à la production d’une application. Chaque titre passait par plusieurs phases : composition, écriture, enregistrement, ajustement, mixage, mastering. Chaque phase était dépendante de la précédente et demandait une validation par toute l’équipe. 

Nous nous fixions un rythme théorique de 2 semaines pour terminer toutes les phases d’un titre. 

Cependant, et contrairement à un produit numérique, la musique ne répond pas directement à un besoin. Son rôle premier est de transmettre des émotions et parfois, un titre qui ne suit pas un chemin de production « standard » comme évoqué précédemment peut être un carton. 

J’ai découvert le test lors de la création d’un jeu pour smartphone dans l’univers de la musique.

Voici quelques softs skills qui m’ont permis de faire une bonne transition dans le monde du test et plus particulièrement sur le rôle de responsable QA :

• Fiabilité : La nécessité de tenir ses engagements auprès des parties prenantes, être rassurant, tenir ses délais,
• Aptitude à fédérer : Mettre en place un collectif durable et tirer le meilleur de chaque individu qui le compose,
• Rigueur : On mise sur un artiste qui lui-même met sa vie en jeu pour atteindre son objectif. Il ne doit pas y avoir de place pour le doute,
• Débrouillardise : Savoir apprendre et trouver des solutions rapidement,
• Capacité à être à l’écoute : Comme tous les métiers créatifs, l’humeur de l’artiste prend une place importante, il faut savoir être à l’écoute.

🎼

Le test est le remède

Sonia Boutaraamt a débuté sa carrière en tant que visiteuse médicale, c’est-à-dire porte-parole de laboratoires pharmaceutiques auprès de professionnels de santé. Une pratique qui a développé sa rigueur et ses compétences en communication.

La visite médicale consiste à rendre visite aux médecins généralistes et ou spécialistes, que ce soit en ville ou en milieu hospitalier. Dans mon cas, c’était les deux. Lors de ces visites, il s’agit de leur faire des rappels sur les spécialités du laboratoire (indications, contre-indications, effets indésirables, posologie), leur présenter les nouveaux médicaments et leur parler des études cliniques récentes. 

Les situations similaires dans le monde de la qualité logicielle sont nombreuses. Elles se concentrent notamment dans la collecte des données et leur exploitation, le reporting, la mise en place de KPI pour atteindre les objectifs. Il y a aussi toute la partie bonnes pratiques et l’habitude de passer des certifications ; en effet, nous n’avions pas le droit d’aller sur le terrain si on était pas certifié tous les 3 mois. J’ai gardé ce côté, j’essaye toujours de me faire certifier au maximum.

En bref, les processus ont une même base : bonnes pratiques, certifications, stratégies (stratégie de test / stratégie commerciale) et politique (politique de test du SI / politique commerciale des laboratoires).

💊

Fuel for test

Quelques jours après la parution de l’article, nous avons eu le plaisir de recevoir un autre témoignage tout aussi inspirant. Il s’agit de celui de Nabil Boulehrouz, précédemment caissier dans une station service pendant 10 ans, avant de reprendre ses études et de se reconvertir dans le test logiciel.

Après quelques années dans le test je me suis rendu compte que le contact avec les clients m’avait facilité le travail avec les développeurs et les autres parties prenantes.

En station-service, quand le client se sert en carburant mais ne peut pas payer, c’est assez compliqué. En effet, là où on peut juste abandonner ses courses dans les autres commerces, en station ce n’est pas possible car le carburant est déjà dans le réservoir. Il faut donc toujours trouver un compromis avec le client. Et chaque client est différent. Avec le temps, j’ai appris à m’adresser de la bonne manière avec les clients pour trouver une solution. Cette « compétence » m’a beaucoup servi dans le test, surtout quand je travaille avec des équipes qui n’ont pas l’habitude de travailler avec un testeur. C’est assez délicat de remonter des bugs au début sans que les développeurs le prennent personnellement.

⛽

Orchestrer la lumière et les tests

Et encore un témoignage bonus avec Sylvain Viole, qui avant d’être QA engineer était régisseur lumière dans le spectacle.

Au moment de ma reconversion je me rappelle avoir beaucoup travaillé sur les ponts entre ces deux activités sans lien à priori.

Mon ancien métier consistait à préparer, installer, programmer et exploiter le matériel technique nécessaire à l’éclairage d’un événement, spectacle ou concert.

Il y a beaucoup de choses dans cette activité dont je me sers aujourd’hui dans mon métier de QA :

• Le repérage et la préparation d’un événement correspond à la lecture et au challenge des spécifications d’un produit. Dans les 2 cas il faut être observateur, précis, le plus exhaustif possible et maîtriser le contexte.
• La programmation séquentielle de lumière (encodage) est très proche de celles de tests automatisés. Dans les 2 cas il faut coder, et factoriser pour simplifier la maintenance.
• Une répétition générale partage les mêmes objectifs qu’un test end to end.
• L’alternance de séquences travaillées et non travaillées (dédiées à la veille et l’autoformation) que l’on peut avoir en ESN ou freelancing peut aussi s’approcher des rythmes d’un régisseur lumière intermittent.

Un point déstabilisant en revanche aura été d’intégrer le côté incrémental des choses dans la tech, là où dans la régie technique le livrable devait être complet dès la première itération. (Parfois, souvent, il n’y en avait qu’une…)

Côté soft skills, l’anticipation, autonomie, l’organisation et la précision sont des qualités auxquelles les 2 activités font appel.

Avant de travailler sur la formulation de ces ponts entre la technique du spectacle et la QA, je trouvais le parallèle un peu tiré par les cheveux. Maintenant que ma reconversion est consommée, je le trouve évident.

💡

Conclusion

Le monde du test s’enrichit de la diversité des profils qui rejoignent cette profession. Les expériences passées construisent les soft-skills et permettent également d’aborder ce nouveau contexte avec un regard plus acéré.

Il n’y a donc pas d’hésitation à avoir si ce métier vous attire ; lancez-vous, vous allez faire des merveilles !

Et pour découvrir d’autres aspects du métier du test, rendez-vous sur notre page LinkedIn 🙂

Photo de couverture : James Wheeler

ODASE est un logiciel permettant de formaliser la réalité du métier, de façon à constituer un référentiel exploitable par une multitude d’applicatifs.

La semaine dernière, nous accueillions Rémi Le Brouster pour nous parler de cette solution, de ses objectifs et du changement de paradigme que cela entraîne pour la définition des règles métier.

Nous nous retrouvons cette semaine pour échanger sur l’intégration de cette solution dans le quotidien des acteurs techniques.

H : Comment les équipes techniques utilisent la représentation du métier définie par ODASE ?

RLB : Avec l’équipe informatique côté client, on définit en parallèle comment ils souhaitent interroger l’outil. On peut par exemple déterminer un ensemble de services pour interroger ODASE, auquel cas on établit alors un contrat d’API. Nous nous occupons alors de réaliser la partie technique qui va proposer les services, transmettre les informations à l’outil, demander le résultat, et le retourner. Ainsi, ni le client, ni le serveur n’ont à connaître le fonctionnement métier.

H : Comment les développeurs accueillent la solution ODASE ? Le fait qu’il y ait besoin de s’interfacer avec un outil tiers complique-t-il leur travail ?

RLB : Les développeurs n’étant pas une entité unique, je suppose que leur accueil de la solution doit varier. Par exemple, je sais qu’en tant que développeur, j’adore me creuser la tête sur des problématiques métiers, définir le périmètre précis et les cas limites, et trouver des algorithmes efficaces, ce que rend obsolète ODASE sur la partie métier, le périmètre et les cas limites étant modélisés en amont, et les résultats étant calculés par l’outil.

H : Est-il possible d’intégrer ODASE au sein d’un SI ayant une forte proportion de legacy, ou est-ce plutôt une solution à privilégier sur des SI naissants ou du moins récents ?

H : Quelle est la plus grande réussite d’ODASE à ce jour ?

RLB : ODASE est actuellement utilisé dans le milieu de l’assurance, ce qui est gage de la fiabilité de l’outil et de l’intérêt de l’approche. C’est une très belle référence pour nous, et notamment de notre capacité à modéliser avec précision des ensembles métiers particulièrement complexes. 

H : Comment ODASE vise à se développer dans les années à venir ?

RLB : Nous sommes en train de créer notre propre outil qui permettra de visualiser et d’éditer les ontologies. L’objectif est que l’ensemble devienne plus simple, intuitif, pratique et confortable d’utilisation. Les étapes clefs sont :

• la visualisation de l’ontologie (concepts et règles), en permettant de construire et enregistrer des vues qui affichent seulement les concepts qui leurs sont pertinents,
• l’édition simple d’attributs ou de règles, pour permettre au métier de gagner de l’autonomie sur ces aspects,
• l’ajout de règles,
• puis de rajouter progressivement différents outils qui sont pratiques ou nécessaires pour les ontologues.

Merci à Rémi Le Brouster pour cette présentation détaillée du fonctionnement d’ODASE !

Il était une fois une entreprise qui avait un système d’information. Dans ce système prospéraient différents applicatifs, plus ou moins récents et plus ou moins bien maintenus. Même s’ils formaient un ensemble hétéroclite et souvent assez bancal, tous ces applicatifs avaient bon nombre de points communs. Premièrement, ils parlaient souvent des mêmes choses (de « clients », de « contrats », de « factures », de « produits »…) Deuxièmement, ils étaient mal documentés, vraiment très mal documentés. Troisièmement, ils faisaient l’objet d’une lutte sans relâche : les équipes techniques refusaient de porter la connaissance fonctionnelle de ces outils, et les équipes fonctionnelles refusaient d’admettre que les équipes techniques ne connaissaient pas leurs règles de gestion.

Les problèmes de cette entreprise étaient aussi épineux que désespérément ordinaires.

Aujourd’hui, notre invité Rémi Le Brouster est avec nous pour parler d’une solution, nommée ODASE, visant à résoudre les problèmes de cette entreprise.

Hightest : Bonjour Rémi ! Tu es directeur technique adjoint de la solution ODASE, et tu étais précédemment développeur. Au cours de ta carrière, as-tu déjà été impliqué au sein d’une entreprise comme celle dont on parlait à l’instant ?

Rémi Le Brouster : Bonjour Hightest ! Ca m’est en effet arrivé, et c’est aussi pour cela que je me suis beaucoup investi pour rejoindre ODASE. J’ai été dans une entreprise très orientée métier, avec une problématique de migration d’un ancien logiciel vers un nouveau, où il fallait donc recouvrer et réimplémenter les règles de gestion. L’ancienne application datant, les spécialistes des différentes parties du métier n’étaient plus tous là, et ceux qui les avaient remplacés étaient parfois contraints de nous répondre de refaire pareil, faute de documentation métier suffisante, ce qui impliquait de fouiller dans le code…

Et évidemment, en voulant réimplémenter les comportements métiers, qu’ils soient historiquement bien réalisés ou fautifs, les développeurs introduisaient aussi de nouveau bugs, ce qui est le lot de presque tout développement.

Je pense également que ce genre de problématiques arrive dans beaucoup d’entreprises, mais avec le chef de service informatique / responsable R&D qui fait le tampon entre le métier et les développeurs, ce qui invisibilise le problème pour ces derniers.

H : Quel est l’objectif d’ODASE ?

RLB : L’objectif d’ODASE est de séparer intégralement le métier de la technique. Le métier doit être garant de la partie métier, tout comme les développeurs doivent se concentrer sur le code et ses problématiques techniques. Pour cela, il faut un outil capable de faire la passerelle entre les deux, se basant donc sur la documentation métier, et qui soit interrogeable via des applications, en leur retournant les résultats calculés souhaités. Cela permet aussi que cette documentation métier soit nécessairement à jour et en phase avec les applications.

Habituellement, dans les systèmes d’information :

• Les spécifications métier peuvent être éparpillées, redondantes, incomplètes, incorrectes, ambiguës.
• Le nombre de lignes de code peut être très important.
• Les changements dus au métier affectent toute l’implémentation.
• Ces changements métiers sont rarement bien documentés, bien qu’ils devraient l’être.
• Le debugging porte tant sur la technique que sur le métier puisque les experts métier n’ont pu intervenir en amont de l’implémentation.

Mettons qu’un SI ait un client lourd et une appli web, voici à quoi cela ressemble classiquement :

Avec ODASE, un certain nombre de choses changent.

• Le métier et la technique sont clairement séparés.
• Le métier est défini en un point unique (l’ontologie et les règles associées).
• L’ontologie est validée en amont avec les experts métier grâce aux explications.
• Il ne peut pas y avoir de contradictions entre le métier et l’implémentation technique.
• Le nombre de lignes de code est très réduit (il ne couvre que la technique).
• Les changements métier ne portent que sur l’ontologie.
• L’ontologie est une documentation de la vérité métier, toujours à jour.
• Les tests de type informatique ne portent que sur la technique.

On se retrouve donc avec une configuration comme suit :

H : Comment fonctionne ODASE ?

L’ontologie se découpe principalement en une représentation des concepts, de leurs attributs et de leurs liens entre eux, et en une spécifications des règles métiers qui définissent l’interaction entre ces différents éléments. Ces règles métiers sont des propositions logiques, ce qui signifient qu’elles sont tout le temps vraies, et qu’il n’y a aucune notion d’ordre entre elles.

H : Pour parler en langage de testeur, ODASE permet de réaliser une analyse statique automatisée du référentiel métier… C’est top ! 

On obtient ainsi une représentation du métier spécifique, compréhensible et validée par le métier, que l’on peut faire évoluer facilement.

H : Mettons qu’ODASE soit installé dans une entreprise où travaillent des testeurs. Quels sont les changements à prévoir dans le quotidien de ces testeurs ? Quelle interaction avec ODASE prévoyez-vous ?

RLB : Tout dépend du contexte. Par exemple, si les testeurs ont une bonne connaissance métier, il peut être pertinent pour l’ontologue d’échanger avec eux, pour essayer d’en extraire de la connaissance métier, en complément des autres sources disponibles.

Les testeurs peuvent également valider, dans les applications techniques, que les résultats obtenus sont les bons. En effet, même si le métier est juste, si les applications qui interrogent ODASE ne fournissent pas les bonnes informations, c’est-à-dire s’ils envoient une mauvaise valeur ou omettent une variable nécessaire dans la construction du JSON de la requête envoyée (dans le cas d’une architecture client/serveur), le résultat sera erroné. Dans cette continuité, les testeurs peuvent également porter leur attention sur l’évolution de l’API, par exemple suite à l’évolution des informations nécessaires d’un point de vue métier, pour tester que ces évolutions ont bien été prises en compte techniquement dans les applications.

H : Quels types de profils deviennent ontologue ?

RLB : Il s’agit en général de docteur·e·s en informatique spécialisé·e·s dans la représentation des connaissances.

H : L’approche d’ODASE rappelle celle du BDD (behavior driven development). Comment se situe ODASE vis-à-vis des outils de BDD ?

RLB : Notre approche étant basée sur des propositions logiques toujours vraies, elle est fondamentalement orientée état. Ainsi, il n’y a pas du tout la notion de « When » des scénarios « Given … When … Then … ». Un état partiel est transmis à ODASE, et ODASE complète le reste. Le comportement, lui, est implémenté au niveau de l’applicatif, de façon technique.

De même, nous cherchons à représenter la réalité métier, de façon indépendante des fonctionnements attendus. Ainsi, ce ne sont pas des tests à passer, ni une volonté stratégique, commerciale ou produit quelconque qui vont régir l’ontologie. La réalisation de l’ontologie est avant tout une quête de la plus pure réalité métier. Les choix ontologiques sont uniquement faits en ce sens. Par contre, on peut s’adapter pour modéliser une partie de cette réalité métier avant une autre.

H : Merci Rémi pour ton temps et tes explications !

Retrouvez l’intégration d’ODASE dans le quotidien des équipes techniques dans la deuxième partie de cet article !

Découvrir ODASE, partie II : intégrer les ontologies dans le SI

PS : Si vous souhaitez en savoir plus, voici l’adresse d’ODASE : info@odase.io

La semaine dernière, nous présentions Promyze (anciennement Themis), une plateforme collaborative agile et ludique permettant d’améliorer en équipe la qualité de code. Nous nous sommes penchés en particulier sur les Ateliers Craft, qui permettent aux équipes de développement d’échanger efficacement sur les bonnes et les mauvaises pratiques au sein de leurs applicatifs. Cette semaine, Promyze répond à quelques-unes de nos questions au sujet des Ateliers Craft.

Les Ateliers Craft au quotidien : quelle temporalité ?

H : Que conseillez-vous pour intégrer la routine des Ateliers Craft dans le quotidien des développeurs ? En Scrum par exemple, quels moments du sprint privilégier ?

P : La temporalité des ateliers va dépendre des cas d’utilisation. Le scénario qui revient régulièrement est celui d’une équipe qui organise des ateliers à chaque sprint, donc soit 1 fois par semaine ou toutes les 2 semaines. Les fins de sprint sont un bon moment pour organiser une rétrospective collective, prendre du recul sur les développements réalisés et échanger sur les pratiques. Ainsi, cela laisse plusieurs jours aux équipes avant la rétrospective pour trouver 10 minutes afin de déposer des tags et suggérer des bonnes pratiques. Les ateliers s’intègrent très bien dans une démarche agile, puisqu’on retrouve l’idée d’interactions collectives et fréquentes et d’amélioration continue. Surtout, cela ritualise un temps d’échange sur le sujet de la qualité de code.

Qui inviter aux Ateliers Craft ?

H : Une entreprise a 3 applications : A, B et C. Son équipe X travaille sur A et B, et son équipe Y travaille sur B et C. Conseillez-vous de laisser chaque équipe se mêler de la qualité de code de ses propres applicatifs seulement ? Ou au contraire conseillez-vous de laisser les ateliers ouverts à tous ?

P : Difficile de généraliser une réponse pour chaque contexte, mais pour les premiers ateliers je préconiserais que chaque équipe travaille sur son propre code, afin de s’approprier le fonctionnement des ateliers et expérimente quelques rétrospectives. Dans un second temps, inviter des personnes externes est une piste intéressante car la richesse des ateliers provient des interactions et des échanges que vont avoir les personnes qui y participent. L’objectif n’est pas de dire “Faites comme ça !”, mais plutôt “Que pensez-vous d’utiliser plutôt cette façon de faire ?”.

Si ces « invités » travaillent sur les mêmes langages et technologies, avoir un regard extérieur est selon moi toujours bénéfique, car non engageant. En effet, l’équipe d’un projet aura toujours le dernier mot, donc il ne s’agit pas d’imposer, mais de suggérer. Le contexte du projet est vraiment primordial, il est donc important que parmi les participants il y ait des membres du projet.

En revanche, nous ne conseillerons pas que l’équipe X organise seule un atelier sur le code du projet C, car elle ne connaît probablement pas le contexte. Par contre, avoir un atelier commun sur le code du projet B avec les équipes X et Y peut être intéressant !

Même si chaque contexte a ses propres règles et bonnes pratiques, c’est important selon nous qu’une organisation définisse un socle commun de bonnes pratiques, que chaque projet viendra enrichir. De plus en plus d’entreprises structurent des “communautés de pratiques” qui vont dans ce sens. Même dans une structure à taille humaine comme chez Promyze, nous nous efforçons d’uniformiser les pratiques sur nos différents projets. Quand une personne change d’équipe, elle a déjà ainsi des repères pour facilement rentrer dans le code !

De la revue à la correction

H : Corriger une mauvaise pratique immédiatement pendant la revue de code est le meilleur moyen de ne pas la laisser tomber aux oubliettes. C’est facile quand la revue se déroule en présentiel, au poste du développeur, mais là ce n’est pas le cas. Comment conseillez-vous de procéder à la correction des mauvaises pratiques identifiées pendant les Ateliers Craft ?

P : Très bonne question qui revient souvent ! Sur ce point, nous sommes d’ailleurs en train de finaliser une fonctionnalité dans Themis qui permettra, lorsqu’on identifie qu’une bonne pratique n’a pas été suivie, de proposer une correction (ex : un refactoring). Cela permettra d’enrichir la documentation de la bonne pratique, et d’échanger avec l’équipe pour savoir si on valide ou non la suggestion de correction. Pour en revenir à la question, nous prônons une démarche d’amélioration continue du code, donc si nous avons identifié des mauvaises pratiques dans l’atelier, le premier objectif sera d’essayer de ne plus l’appliquer sur les prochains développements. Par la suite, si l’on travaille sur du code existant, et qu’on identifie une mauvaise pratique, alors à ce moment-là il peut s’avérer judicieux de le retravailler pour qu’il respecte la bonne pratique définie dans l’atelier. Il faudra évidemment veiller aux risques de régressions, donc coupler les tests et les développements est fondamental. Enfin, la correction à apporter va dépendre du niveau de criticité : s’il y a potentiellement un bug derrière une mauvaise pratique, on sera forcément plus réactif dans le passage à l’action !

Comment organiser les ateliers ?

H : Il est possible de créer des ateliers à volonté. Comment les organiser ? Est-il conseillé par exemple de tenir des ateliers thématiques ? Comment savoir quand un atelier est terminé ?

P : Nous préconisons d’organiser des ateliers thématiques (ex : HTML/CSS, NodeJS, Spring, …), au sein desquels plusieurs sessions pourront être organisées. Il n’y a qu’une seule session en cours par atelier, donc cela facilite l’organisation. Plusieurs ateliers peuvent être créés en parallèle, mais généralement un seul sera actif chaque semaine par équipe. Pour chaque session, une personne dans l’équipe est désignée comme animateur, et aura pour mission de définir le code source sur lequel travailler, d’envoyer des rappels aux participants et enfin d’organiser la rétrospective. Nous préconisons qu’à chaque démarrage de session, la rétrospective soit notée dans l’agenda de l’équipe, cela permet à chacun et chacune de s’organiser ! Enfin, avoir une rotation dans les thématiques permet de rythmer les échanges et d’apporter de la diversité, mais aussi de revenir quelques semaines plus tard sur une thématique avec un regard qui aura peut être évolué.

Enfin, nous préconisons aussi de préparer le prochain atelier dès la fin de la rétrospective, en désignant qui sera la personne en charge de l’organisation et à quelle date on peut planifier la future rétrospective.

Les guégerres de bonnes pratiques

H : Il y a parfois des querelles autour des bonnes pratiques. Typiquement, il n’est pas rarissime de voir deux devs seniors, tous deux excellents, se crêper le chignon sur telle pratique, que X qualifiera de bonne et Y d’antipattern. Comment les Ateliers Craft permettent-ils de sortir de ces impasses ?

P : Effectivement cela peut arriver que, sur le moment, des personnes ne soient pas d’accord sur une bonne pratique. C’est déjà quelque chose de positif, ça montre qu’il y a de la matière pour échanger des arguments et arriver à un consensus ! Mais pour rebondir sur la question précédente, il est important d’avoir une personne qui soit “facilitateur” lors d’une rétrospective, anime les échanges, invite les participants à s’exprimer, … Cette personne doit être en mesure de sentir si un consensus va rapidement être trouvé lors de la rétrospective ou non, et si ce n’est pas le cas, la pratique qui fait débat est temporairement mise de côté, pour laisser le temps à l’équipe d’y réfléchir et d’exposer des arguments. Ce n’est pas évident de trancher à chaud sur des sujets pointus ! Themis proposera d’ailleurs très bientôt une fonctionnalité dans ce sens, un mode “battle” avec un système de vote qui offrira la possibilité d’apporter des arguments “pour” ou “contre”.

Themis vu de l’intérieur

H : Ca va être énorme ! Et chez Promyze, comment utilisez-vous les Ateliers Craft ?

P : Nous utilisons les ateliers une fois par semaine en organisant la rétrospective le vendredi après-midi. C’est une bonne opportunité pour tous et toutes de se retrouver pour parler de qualité de code et terminer la semaine ensemble. Notre objectif est de ne pas dépasser 1 heure, c’est important de borner les échanges. En pratique, nous conseillons à nos utilisateurs de viser 30 à 45 minutes.

Au début, nous avons forcément été les premiers testeurs de cette fonctionnalité, donc plusieurs formats ont été expérimentés (notamment sur le nombre de fichiers, de tags que l’on pouvait poser, …). Cela nous a aidés à optimiser l’utilisation des ateliers et d’en faire profiter nos clients.

Nous définissons la thématique de chaque session d’atelier, et désignons une personne pour animer la future rétrospective de cette session. Nous mettons en place une rotation dans la thématique des ateliers (HTML/CSS, NodeJS, Tests unitaires, …). C’est très positif jusqu’à présent, en plus nous avons dans notre équipe des profils avec des parcours différents, cela amène de la richesse dans nos échanges !

Merci à Promyze d’avoir répondu à nos questions sur Themis. Longue vie à cet outil qui apporte énormément au processus d’amélioration continue !

Dans l’article précédent, nous proposions quelques ressources pour (mieux) appréhender le Behavior Driven Development. Mais quid de l’implémentation de cette méthodologie dans le cadre de projets dont le code historique (ou legacy) représente une part très importante ? Florent Vaution, Software QA Manager chez Ouest-France, a tenté l’expérience et présente ici son témoignage.

Origines de la démarche

Quel contexte de départ ?

A mon arrivée chez Ouest-France il y près de 3 ans, un parcours d’intégration est organisé et me permet de rencontrer différents acteurs qui gravitent autour du SI : métiers du commerce/marketing, métiers du numérique, journalistes, membres de la DSI. A cette occasion, je fais rapidement deux constats :

• Le premier est qu’il y avait un manque de confiance des équipes métiers vis à vis de la production de la DSI. C’est pourquoi les équipes métiers vérifiaient systématiquement tous les cas d’usages, nominaux ou non, sur les produits livrés. Et, bien souvent, dès qu’un problème survient, les équipes de la DSI étaient pointées du doigt.
• Le second est que les membres de la DSI se désengagent petit à petit de la qualité de leur production. Ils souffrent de cette défiance et du manque de sens par rapport à ce qu’on leur demande de produire.

Beaucoup plus proche de mon métier, je note aussi un manque cruel de formalisation des tests ainsi qu’une documentation pas forcément à jour, ou quand elle l’est, l’effort important de mise à jour en cas d’évolution.

Qui a eu cette idée folle ?

L’idée de rapprocher ces acteurs via une approche BDD émerge assez rapidement. Avec pour objectifs de casser cette défiance, de faire comprendre aux métiers les contraintes et problématiques de la DSI, de redonner du sens aux équipes techniques vis à vis de ce qu’elles produisent pour qu’elles s’investissent et s’approprient leur production. Et ceci pour tous les services de la DSI, des sites web à la distribution du journal dans les boîtes aux lettres des abonnés, de la gestion du compte client à l’impression quotidienne du journal papier.

Un challenge quotidien !

Dans les coulisses de Ouest-France

OK, pour le BDD on comprend bien. Mais il est où le legacy là-dedans ?

Faisons un focus sur cette performance quotidienne qui est d’imprimer tous les jours à près de 600 000 exemplaires du journal papier divisés en 52 éditions (une édition correspond à une zone géographique précise, la zone de Rennes représente 5 éditions par exemple : centre, est, nord, ouest, sud, et chaque édition comporte des pages locales différentes) et répartis sur 3 imprimeries différentes. Ce miracle est possible principalement grâce à un gros legacy. La majorité des applications sont âgées de 15 – 20 ans, et il y a, heureusement, très très très peu de turn-over. Ce qui signifie qu’une partie des personnes qui ont créé ces applications sont toujours présentes et donc qu’elles sont très bien maîtrisées et peu soumises aux défauts.

Les rotatives de Ouest-France, à Rennes le 24 novembre 2014 afp.com/DAMIEN MEYER

L’équipe technique de la DSI est en charge de maintenir et faire évoluer les solutions de mise en page et d’impression du journal papier.

Au niveau organisation, l’équipe technique de la DSI est constituée de PPO, de 5 développeurs, d’un scrum master et d’un testeur. Une petite équipe pour gérer un petite trentaine d’applications différentes. Le legacy est géré grâce à la méthodologie Kanban. Les applications plus récentes et encore en cours de développement sont gérées par la méthodologie Scrum.

Mon rôle dans cette organisation est d’aider à établir la stratégie de test sur les différentes applications développées, de partager les bonnes pratiques venant d’autres équipes et d’accompagner les membres de l’équipe dans ce changement pour qu’il se passe de la meilleure façon possible. A noter que la démarche est aussi déployée dans plusieurs autres équipes.

Côté documentation des différents applicatifs, elle est maintenue sous Word depuis leur création. Côté tests, uniquement des campagnes de non régression étaient présentes dans Testlink mais sans réelle traçabilité avec les “exigences”.

Un journal, trois domaines fonctionnels

Les solutions développées sont utilisées au sein de trois domaines fonctionnels :

• celui des journalistes, qui créent la maquette éditoriale du journal qui partira à l’impression le soir même
• celui des coordinateurs, qui s’assurent que les 52 éditions différentes sont complètes avec leurs publicités respectives, leurs avis d’obsèques, leurs annonces légales…
• celui de l’impression en elle-même. On entre dans le domaine industriel (rotatives)

La qualité : un enjeu crucial

Mais pas facile de faire évoluer un processus industriel qui doit fonctionner tous les jours et qui est soumis aux aléas de l’actualité ! En effet, une information de très grande importance et qui arrive tardivement après le bouclage, peut nécessiter une reprise de la maquette complète du journal (modification, ajouts ou suppression de pages). Les applications mises à disposition doivent donc être prêtes à aborder ces dernières nouvelles.

Le moindre défaut sur cette chaîne peut prendre des proportions considérables : maquette éditoriale à revoir donc décalage de l’impression et distribution plus tendue, remplacement de publicités donc perte de CA et de confiance des annonceurs déjà peu nombreux, non impression de tout ou partie des éditions donc perte de CA. A titre d’exemple, ne rien imprimer représente une perte quotidienne de 600K€ environ.

Passer au BDD : notre plan d’action

C’est dans ce contexte très établi que je mets les pieds dans le plat. Heureusement, mon discours a un écho favorable auprès de plusieurs personnes, notamment auprès du DSI,  et nous mettons en place un plan d’action en 3 étapes.

© investissements.org

Première étape : expliquer la démarche

Pourquoi changer ? Cette question, je l’ai entendue souvent. Et il m’arrive encore de l’entendre. La réponse n’est pas évidente quand on est sur un système qui fonctionne, qui permet de produire correctement le journal tous les jours. Néanmoins, nous arrivons aux limites d’un système. Les applications sont basées sur des technologies anciennes, une partie des personnes qui y ont contribué est passée à autre chose (mobilité interne, retraite). Se pose donc la question de la mise à jour et de l’évolution de ces applications.

C’est une réelle opportunité pour démarrer la démarche BDD !

J’ai donc commencé par mettre au point une formation pour expliquer ce qu’est le BDD et ce que j’en attends : de la collaboration entre équipes métiers et équipes techniques !

La formation mêle les concepts théoriques et des ateliers pratiques de réflexion collective pour répondre à un besoin. Le besoin est fictif et volontairement hors de leur champ de compétences mais on peut aussi prendre des cas très concrets.

Bien sûr, l’aspect formalisation qui accompagne cette démarche est abordé et quelques règles sont données pour bien commencer.

L’écho de cette formation a été plutôt bon, et quelques jours plus tard l’équipe a décidé de se lancer dans la démarche. Les membres de l’équipe ont donc bien saisi l’opportunité qui s’offraient à eux.

Nous avons alors défini un plan d’accompagnement pour supporter la démarche et rendre l’expérience la plus bénéfique possible.

Deuxième étape : profiter d’un contexte d’évolution sur un produit exemple

Un POC interne

Nous avons défini ensemble le contexte le plus favorable pour se lancer. Et nous avons profité de l’évolution mineure d’une application existante. L’idée était double :

• traiter l’évolution avec cette nouvelle méthode
• valider la démarche avec l’équipe sur un cas concret de leur périmètre

Nous avons fait le choix de mettre le testeur de l’équipe au centre de la mise en place de cette démarche. Nous avons estimé qu’il était le mieux placé pour à la fois formaliser les discussions autour de l’évolution et exprimer des contraintes de test.

Faux départ et rollback

Le plan ne s’est malheureusement pas déroulé sans accroc. L’écueil que nous avons rencontré est que ce testeur n’avait finalement pas totalement saisi les objectifs et qu’il a aussi repris la totalité des fonctionnalités de l’application mais d’une mauvaise façon. Le testeur a utilisé une méthode très directive avec une action par step. Ce qui inclut des steps techniques non compréhensibles par l’ensemble des membres de l’équipe. On est alors en contradiction avec les principes premiers de la démarche BDD.

Ce qui fait que nous nous sommes donc retrouvés avec un patrimoine de plusieurs centaines de scénarios inutilisables. Grosse frustration du testeur et de moi-même, et léger moment de doute. Mais on se remotive collectivement car on se dit que c’est tout de même la bonne démarche !

© reussitepersonnelle.com

Donc on efface tout et on recommence. J’ai fait des ateliers plus précis avec lui et le Scrum Master pour s’assurer que nous étions tous sur la même longueur d’ondes. Ces ateliers étaient basés sur des cas très concrets et mettaient en avant l’aspect collaboratif. Pourquoi ces 2 personnes uniquement ? Parce que le testeur se faisait le représentant de l’équipe technique et le Scrum Master le représentant de l’équipe métier. Je dis bien le Scrum Master car :

• c’est lui qui a le plus de connaissances métier dans l’équipe et donc qui peut rapidement dire si un scénario est compréhensible ou non
• c’est lui qu’il faut surtout convaincre
• il n’y a pas de PO mais plusieurs PPO qui ont été épargnés lors de cette première phase pour qu’ils continuent à avancer sur les sujets opérationnels

Et aussi tout simplement parce que ces deux personnes sont les plus à même à faire passer des messages au quotidien à l’ensemble de l’équipe.

Donc nous sommes repartis pour un tour. Au-delà de l’aspect perte de temps engendrée par cet écueil, cela a permis de montrer que cette démarche BDD n’est pas si évidente que cela à formaliser afin que tout le monde ait le niveau d’information suffisant et la même compréhension d’une fonctionnalité.

Quand la BDD-mayonnaise prend…

Une autre question s’est aussi levée au début de la démarche : doit-on aussi mettre à jour la documentation existante (Word) ? Nous avons collectivement fait le choix de ne pas le faire. Cela démontre l’adhésion à la démarche initiée et la volonté de la faire aboutir.

Une fois le bon niveau de formalisation atteint, il a fallu reprendre l’existant depuis la documentation existante afin d’obtenir une documentation centralisée et facilement évolutive.

La suite a été la prise en main de la démarche par l’ensemble de l’équipe. Nous avons poursuivi la démarche en ajustant les pratiques avec l’ensemble des membres de l’équipe pour atteindre la bonne façon de faire. Quand je dis la bonne façon de faire, cela signifie que c’est la façon qui convient à tous les membres de l’équipe.

Et ça fonctionne bien ! Les membres de de l’équipe ont bien sûr eu une période de prise en main nécessaire. D’où l’intérêt d’avoir deux personnes à leurs côtés pour échanger, corriger, améliorer leurs pratiques, de manière collaborative. Néanmoins, l’équipe s’est révélée opérationnelle dans l’application de la démarche BDD.

Troisième étape : déployer la démarche sur les autres produits

Mise à profit du retour d’expérience

Une fois cette étape franchie sur une application, il faut réfléchir au déploiement de la démarche sur les quelque trente autres.

Nous avons appliqué la même tactique qu’avec la première : toujours profiter des  opportunités engendrées par les évolutions, les refontes de produit, les nouveaux développements. C’est donc au gré des événements que le déploiement s’est déroulé et continue à se dérouler car toutes les applications n’ont pas subi d’évolutions et donc ne sont pas inscrites dans la démarche BDD. A ce jour, 16 applications voient leur développement guidé par cette démarche collaborative. Les autres suivront tôt ou tard. Les équipes sont prêtes.

Nouvelle péripétie !

Mais comme rien n’est parfait dans ce bas monde, nous avons dû faire face à un imprévu en cours de route : le départ du testeur qui avait entamé la démarche et qui en était le référent dans l’équipe. Nous avons donc entamé des recherches pour le remplacer et pour poursuivre l’effort au sein de l’équipe. C’était un coup dur car la dynamique était bonne et cet évènement risquait de balayer tous les efforts accomplis.

De plus, trouver la bonne personne pour animer la démarche au quotidien n’a pas été une chose facile.Il faut mêler de bonnes compétences en test (c’est quand même le métier premier) et des soft skills pour embarquer rapidement dans la démarche et l’animer au quotidien. Une combinaison pas si courante que ça autour de nous.

En effet, ce n’est pas parce que les autres membres de l’équipe sont autonomes qu’il n’y a plus rien à faire. C’est peut-être même à ce moment que l’effort doit être plus important pour toujours chercher de l’amélioration, ne pas s’endormir sur des certitudes. Et donc, il faut un animateur de la démarche, un référent, qui peut pousser les autres membres de l’équipe à s’améliorer, à penser à tous les impacts d’une évolution, qui peut s’assurer que tout se déroule correctement, qu’il n’y a pas de raccourci de fait, qui peut répondre à des questions sur la méthode, l’outillage …

L’heure du bilan : qu’a apporté le BDD ?

© resonances-vs.ch/

Vous me direz, c’est bien beau tout ça, mais est-ce que c’est efficace ?

Très bonne question. Je rappelle les objectifs initiaux :

• casser la défiance des équipes métiers vis-à-vis des équipes de la DSI,
• faire comprendre aux équipes métiers les contraintes et problématiques de la DSI,
• redonner du sens aux équipes techniques vis à vis de ce qu’elles produisent pour qu’elles s’investissent et s’approprient leur production

J’ajoute à ces objectifs des choses plus terre à terre tel que l’amélioration globale de la qualité des produits développés, la réduction du temps de conception d’une nouvelle fonctionnalité, la réduction du temps de maintenance de la documentation.

Amélioration des relations inter-équipes

Concernant la défiance, nous n’y sommes pas encore tout à fait. Il existe encore de grosses phases de recette métier après plusieurs itérations de développement et malgré tous les tests effectués par l’équipe technique. Dans notre cas, il y a aussi une dimension organisationnelle : l’équipe n’a pas accès à un journaliste pour lui servir de Product Owner. Si nous nous cantonnons au PPO (Proxy Product Owner), alors il y a du mieux car il a gagné la compréhension des contraintes techniques à travers les échanges systématiques avec l’équipe technique.

Reprise de sens du travail de développement

Pour ce qui est de redonner du sens aux équipes techniques, c’est difficile de se prononcer, notamment sur la partie legacy qui n’évolue pas ou peu. Si on regarde les applications plus récentes et celles qui ont bénéficié des plus grosses évolutions, alors on peut dire que l’implication est supérieure. C’est encore plus flagrant sur les nouveaux développements lancés après la mise en place de la démarche BDD et qui bénéficient depuis le début de ses bienfaits.

Performance de l’équipe

Si on regarde les objectifs plus terre à terre, l’amélioration de la qualité est difficile à mesurer (d’ailleurs comment mesure-t-on la qualité ? Hightest et Brice Roselier proposent quelques pistes dans cet article). Ce que je peux dire c’est qu’il n’y a pas eu de dégradation car le journal est imprimé tous les jours. Il y a bien sûr des incidents de temps à autre mais rien qui n’empêche la sortie sur les rotatives.

A propos de la réduction du temps de conception d’une nouvelle fonctionnalité, j’ai du mal à quantifier s’il y a eu un progrès. Ceci est dû au fait que la méthode BDD demande un effort plus important que ce qu’ils pratiquaient auparavant. Elle apporte aussi une réalisation meilleure du premier coup. Mais comme les mises en production sont au mieux trimestrielles, l’équipe technique a le temps de faire les choses…

Le paramètre sur lequel on voit la plus grande amélioration est la maintenance de la documentation. Fini la spec qui mêle le besoin et la solution. Nous avons d’un côté la documentation des fonctionnalités exprimées du point de vue des utilisateurs, et de l’autre la documentation technique de la solution. Ainsi si l’implémentation de la solution change, la documentation fonctionnelle n’a pas à être touchée. Et dès le moindre changement fonctionnel, la documentation est mise à jour automatiquement. Ce qui permet aux membres de l’équipe de toujours avoir une référence documentaire à jour.

Conclusion

La mise en place d’une démarche BDD dans un contexte où le legacy est très majoritaire n’est pas une pratique évidente à mettre en oeuvre. Il faut une équipe volontaire, qui croit en la démarche et qui souhaite s’y investir. Car c’est un investissement. Et pas sur du court terme mais plutôt sur du moyen-long terme, le temps de reprendre petit à petit un existant qui peut être conséquent.

Des questions restent toujours ouvertes (traçabilité des changements, granularité des scénarios, …) et les axes d’amélioration sont encore nombreux. Ce qui est sain et encourageant car c’est un signe que les personnes qui intègrent la démarche sont pleinement investis !

Sachez profiter des événements qui seront un terreau bénéfique à la mise en place de la méthode.

Préparez le terrain avec des formations, des ateliers pour accompagner les équipes dans ce changement.

Chaque équipe est différente, adaptez-vous !

Identifiez les relais dans les équipes qui porteront au quotidien la démarche.

Merci à Florent Vaution de Ouest-France pour ce témoignage inspirant, et bon courage aux QA qui se lancent ou se démènent déjà pour mettre en place une démarche de BDD dans leur organisation !

Crédit image couverture : © Ouest-France

Une autre vision du web

Portrait d’un regard

Entrepreneuse, mère de famille et engagée dans diverses associations calédoniennes, Marie-Françoise Pierre passe une grande partie de ses journées devant des écrans. Nous l’avons rencontrée pour nous immerger dans sa vie numérique, qui est adaptée à son handicap : la malvoyance.

Dans cet article, nous allons présenter une vie numérique parmi des millions d’autres, en espérant qu’elle vous aidera à imaginer des sites plus accessibles, mais aussi détecter des problèmes d’accessibilité et en parler pour qu’ils soient corrigés.

Comment voit Marie ?

La déficience oculaire de Marie touche la partie centrale de sa rétine, la macula, ce qui affecte le centre de sa vision. Sa vision périphérique, en revanche, lui permet de se situer dans l’espace et de se déplacer sans problème. Cette déficience l’handicape à 80% ; certaines actions ne lui sont pas possibles, par exemple la conduite.

D’autres types de malvoyances impactent uniquement la vision périphérique, ce qui permet aux personnes de pratiquer des activités demandant une acuité visuelle fine, mais peut représenter un risque important lorsque des dangers surviennent sur les côtés.

Pour Marie, avoir une bonne hygiène de vie est impératif pour voir le mieux possible : une fatigue ou un manque de sommeil peuvent lui rendre encore plus difficile la lecture, voire lui occasionner des vertiges.

Si vous souhaitez expérimenter par vous-mêmes la façon dont Marie voit le monde, vous pouvez télécharger l’application Eye-View (disponible sur iOs et Android) et essayer la vue « DMLA » en agrandissant au maximum la tache grise centrale. Gardez bien votre regard au centre de la tache et laissez votre vision périphérique faire le reste… Pas facile !

Des équipements matériels et logiciels pour plus d’accessibilité

Chez Marie, tout est Mac : ordinateur, tablette et smartphone, car tous ces matériels intègrent directement des fonctions d’accessibilité pour les déficients visuels. Sinon sur PC, Marie doit être équipée du logiciel ZoomText, un logiciel qui coûte cher acheté individuellement (environ 60 000 francs pacifiques). Ces outils permettent de régler la taille du texte, la teinte et le contraste des couleurs, l’apparence du curseur, et propose également une synthèse vocale. Mais le plus souvent, Marie préfère ne pas utiliser la synthèse vocale ; elle a remarqué que celle-ci a tendance à s’entrecouper, répéter plusieurs fois la même chose, ou encore énoncer un autre texte que celui souhaité. Elle préfère lire elle-même les textes, aussi bien dans les visionneuses de documents que dans son client mail ou son navigateur.

Elle maîtrise Siri et a formé d’autres personnes dans le cadre l’association Valentin Hauÿ de Nouméa, mais a l’habitude d’écrire ses mails et autres messages au clavier.

Marie lit avec fluidité à condition que le texte soit à une taille suffisante (police 72 pour un document word affiché à 100%). Il est préférable aussi que la police soit sobre, sans empattements (lire cet article pour comprendre pourquoi !). Pour lire un texte, elle zoome au maximum, fait défiler la page horizontalement avec la souris, dézoome, rezoome… Toute une gymnastique qu’elle fait maintenant sans y penser. Elle explique qu’au départ ça donne un peu envie de vomir, mais qu’on s’y habitue vite.

Le clavier de Marie est tout à fait classique. Pour écrire avec plus d’aisance, elle y a simplement collé deux petits reliefs en plastique qui lui permettent de placer ses mains au bon endroit.

Elle utilise souvent l’appareil photo de son téléphone pour zoomer certains textes rencontrés dans la vie de tous les jours, par exemple des plaques portant un nom de rue, ou les cahiers d’école de ses enfants.

Des bugs auxquels vous n’auriez peut-être jamais pensé

Vous souhaitez construire des logiciels (plus) accessibles ? Voici maintenant des points soulevés par Marie au cours de sa vie d’internaute. Peut-être repenserez-vous à ces cas d’utilisation lors de votre prochaine phase de spécifications… Car une fonctionnalité qui semble parfaite pour une personne valide peut être perçue comme buggée (ou « buggante ») lorsque l’on navigue différemment.

Le menu glissant

Imaginez un site web avec un bandeau comprenant différents onglets thématiques. Lorsque vous survolez un onglet avec la souris, un menu apparaît. Et lorsque vous survolez un item de ce menu, un sous-menu apparaît. Et lorsque la souris quitte soit l’onglet, soit le menu, soit le sous-menu… Tout se replie.

Ce type de design est très courant, en particulier sur les sites de vente ; à peu près gérable quand l’écran est affiché à 100%, il devient cauchemardesque s’il est zoomé à 500%. Comment garder la souris sur ces éléments tout en faisant défiler l’écran horizontalement ? Ces menus interactifs peuvent devenir un casse-tête.

Le carrousel vertigineux

Certains carrousels d’images défilent automatiquement et nécessitent que l’on identifie rapidement les informations utiles et qu’on les lise dans la foulée. Or, pour Marie, l’étape d’identification est plus longue que prévu ; ce qui était censé être une animation agréable et vivante devient une chasse agaçante où l’on joue au chat et à la souris.

Le captcha indéchiffrable

Les captchas sont des outils plus ou moins efficaces pour limiter l’accès des robots sur certaines parties du web. Mais ils ne sont pas toujours accessibles : les lettres indéchiffrables et les contrastes insuffisants bloquent parfois à Marie l’accès à certains services.

Le curseur fugitif

Dans certaines applications, Marie a remarqué que lorsqu’on zoome au maximum un champ où l’on est en train de saisir du texte, le focus de l’écran ne suit pas automatiquement le curseur. Du coup, lorsque le curseur quitte l’écran, on ne voit plus ce qu’on écrit. Elle a remarqué ce comportement en particulier sur son client de messagerie.

La barre qui s’incruste

Quand Marie regarde une vidéo, elle n’a pas le temps de lire les sous-titres. Mais lorsqu’elle a besoin de les lire et qu’elle appuie sur « Pause », il arrive que la barre de lecture cache la partie basse de la vidéo, ce qui masque le texte.

Cette petite série de bugs n’est qu’un échantillon des embûches que l’on peut rencontrer lorsqu’on navigue autrement que ce qui était imaginé par le concepteur d’un site web. La prochaine fois que vous ouvrirez un site (probablement dans moins de quelques minutes), regardez-le avec un oeil différent ; quelles parties vous semblent bien pensées pour l’accessibilité ? Quelles parties laissent à désirer ? Adopter ce regard nécessite de l’entraînement, et des méthodes et outils peuvent vous aider à le faire, comme nous en parlions précédemment.

L’accessibilité, ce n’est pas que pour les autres

Au cours de sa vie professionnelle, Marie a remarqué que les logiciels destinés à un usage interne étaient souvent moins soignés en termes d’ergonomie et d’accessibilité que les logiciels ouverts à un public plus large. Un constat qui laisse pensif, à l’heure où l’insertion des personnes handicapées devrait être un enjeu important des entreprises.

Pourtant, au bureau ou ailleurs, la majorité des mesures d’accessibilité sont profitables autant aux personnes handicapées qu’aux autres. N’importe qui pourrait avoir besoin de capter toutes les infos d’un site sans se baser sur les images (sa connexion étant trop lente pour les charger par exemple), et donc de se servir des attributs de texte alternatif. N’importe qui, souffrant d’une migraine passagère ou de fatigue oculaire, pourrait apprécier un site dont les contrastes respectent les normes d’accessibilité.

Cela est vrai aussi « dans la vraie vie »… Vous le savez s’il vous arrive de préférer monter via la pente douce plutôt que par les escaliers.

N’hésitez pas à partager dans les commentaires votre expérience du handicap, de l’accessibilité et des bugs associés que vous avez rencontrés !

Autres articles sur le thème de l’accessibilité

Chiffres sur l’accessibilité du web calédonien

30 days of accessibility testing