L’accessibilité, mieux vaut y penser en amont du projet, lors du cadrage et de la définition des exigences.
D’accord, mais si ce sujet est passé à la trappe, est-ce que c’est trop tard ?
Bien sûr que non 😉
La première chose à faire (temps : 5 minutes)
Si votre site web existe déjà, vous pouvez vous aider d’outils très simples d’utilisation pour effectuer un diagnostic rapide.
Des extensions de navigateur gratuites telles que WAVE vous donneront des informations de base. C’est avec WAVE que nous avons réalisé l’audit de l’accessibilité du web calédonien l’an dernier (lien vers la vidéo) !
Pour creuser un peu plus (temps : une heure)
L’extension de navigateur va vous fournir des informations de base que vous pourrez communiquer à votre équipe.
Mais il est important de se plonger un peu plus dans ce qui sous-tend l’écrasante majorité des outils d’accessibilité : les WCAG.
WCAG veut dire “Web Content Accessibility Guidelines” (en bon français, “Règles pour l’accessibilité des contenus web”). Ces règles ne datent pas d’hier : les premiers pas des WCAG ont eu lieu 1995, il y a donc 30 ans !
Ces règles sont aujourd’hui au nombre de 13, et réparties en 4 principes. Il faut que les services soient :
Perceptibles
Utilisables
Compréhensibles
Robustes
Chaque règle a ses propres critères de réussite, positionnés sur 3 niveaux : A, AA et AAA (AAA étant le niveau le plus exigeant).
Nous vous recommandons de prendre une heure pour explorer ces 13 règles, qui sont résumées ici.
Pour gagner en profondeur (temps : toute une vie)
L’accessibilité est un principe d’apparence simple, mais qui soulève énormément de questions.
Pour gagner en profondeur de réflexion, la meilleure chose à faire est d’aller à la rencontre des personnes qui sont le plus souvent confrontées à ces problématiques.
C’est une démarche que nous avons initiée dès 2018 lorsque nous avons fait la connaissance de Marie-Françoise Pierre, entrepreneuse malvoyante, qui nous a appris beaucoup de choses en nous présentant concrètement sa vie numérique.
Cette année, nous avons également eu la chance d’échanger avec Cyriaque Delaveau, développeur web, dont le handicap moteur l’amène à utiliser ses outils numériques avec les yeux, grâce à une commande oculaire.
Ces deux personnes sont calédoniennes et leurs profils, même s’ils sont individuellement rares, ne sont pas isolés ! L’accessibilité peut être un sujet qui semble lointain au premier abord, mais il faut se souvenir que les handicaps ne sont pas toujours visibles et concernent une partie importante de la population.
Si elles sont ouvertes à la discussion, prenez le temps d’interroger les personnes que vous rencontrez sur leurs problématiques particulières : c’est aussi ainsi que vous développerez un regard plus aiguisé sur l’accessibilité numérique.
En 2024, pour partager sa passion du test en Nouvelle-Calédonie comme ailleurs, Hightest a publié un post LinkedIn par jour ouvrable !
Cette page fournit un best of de ces posts, afin de vous permettre (et aussi de nous permettre, car parfois nous en avons besoin nous-mêmes !) de retrouver un sujet ou une discussion passée. Nous avons choisi un classement par thématiques plutôt que par date.
Nous avons beaucoup repartagé des pépites produites par notre réseau et remercions au passage la communauté francophone du test logiciel pour sa créativité et son dynamisme.
Cela vous donnera peut-être envie à vous aussi de partager votre quotidien de QA… On l’espère en tous cas !
C’était un plaisir d’échanger sur LinkedIn avec une multitude de personnes passionnées par la qualité logicielle. Et si on réitérait le défi en 2025 ? 😉
En feuilletant un syllabus ISTQB, vous avez peut-être rencontré les termes de “bouchon” (“stub” en anglais) et “pilote” (“driver”). Vous souhaitez clarifier ces notions ? Cet article est pour vous !
Les définitions officielles
Voici les définitions de ces termes tels qu’ils apparaissent dans le glossaire ISTQB.
Bouchon
Type de doublon de test fournissant des réponses prédéfinies.
Pilote
Un composant ou un outil temporaire qui remplace un autre composant et contrôle ou appelle un élément de test de manière isolée.
Ces définitions sont très concises et méritent un petit approfondissement pour y voir plus clair !
Pour comprendre ce qu’est un bouchon, on peut imaginer une comédienne qui doit répéter un passage, mais son acolyte de scène est encore en route. Pas question d’attendre. Une doublure la rejoint alors sur les planches avec le texte imprimé. À chaque fois que la comédienne dit une réplique, elle lit les réponses de la personne absente.
Un bouchon, c’est comme cette doublure. C’est une simulation de composant qui remplace un autre composant logiciel. Cela peut être pour deux raisons : soit ce composant n’est pas encore disponible, soit on veut réaliser un test en isolant bien les composants.
Imaginons un service en ligne qui permet de calculer les frais d’expédition d’un colis et d’imprimer un timbre en conséquence. Tout est prêt, sauf l’interface avec le service externe qui fournit les tarifs postaux en fonction du poids du colis. Un bouchon peut alors être utilisé pour simuler ce service, et ainsi permettre de réaliser une première simulation du scénario final.
Qu’est-ce qu’un pilote ?
Là encore, utilisons une métaphore ! Un pilote est un composant qui, comme son nom l’indique, va venir diriger, “donner des ordres” au composant à tester. Le pilote est la télécommande, la voiture télécommandée est le composant à tester.
Reprenons le même exemple avec une variante. Si le composant de calcul des frais d’expédition prêt mais que l’interface cliente n’est pas encore développée, un pilote peut être utilisé pour simuler cette interface et fournir les entrées nécessaires. Ainsi, on peut vérifier que le calcul est correct sans avoir à attendre que l’interface soit terminée.
Des petits bouts de code pour expliquer
Un petit bouchon
// Bouchon pour le service de tarifs
public class BouchonTarifsPostaux {
public double getTarifExpedition(String destination) {
// Retourne des tarifs fixes en attendant les "vrais"
if (destination.equals("local")) {
return 5.0;
} else {
return 10.0;
}
}
}
Ce bouchon pourrait être utilisé dans cette classe :
public class CalculatriceDeTarifs {
private BouchonTarifsPostaux bouchon;
public CalculatriceDeTarifs(BouchonTarifsPostaux bouchon) {
this.bouchon = bouchon;
}
public double calculPrixExpedition(String destination, double poids) {
double tarif = bouchon.getTarifExpedition(destination);
return tarif * poids;
}
}
Un petit pilote
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;
public class TestCalculPrix {
@Test
public void testCalculPrixExpedition() {
// Utilisation du bouchon
BouchonTarifsPostaux bouchon = new BouchonTarifsPostaux(); // Création du bouchon
CalculatriceDeTarifs calculatrice = new CalculatriceDeTarifs(bouchon); //
// **Pilote**
double prix = calculatrice.calculPrixExpedition("local", 2.0);
assertEquals(10.0, prix, "Le coût d'expédition pour une expédition locale devrait être 10.0");
prix = calculatrice.calculPrixExpedition("international", 3.0); // Appel de la méthode à tester
assertEquals(30.0, prix, "Le coût d'expédition pour une expédition internationale devrait être 30.0");
}
}
Explications
Le bouchon (BouchonTarifsPostaux) simule le service de tarifs postaux, fournissant des tarifs fixes pour les destinations.
Le pilote est le test unitaire (TestCalculPrix). Il initialise les objets nécessaires, appelle la méthode à tester (calculPrixExpedition) et vérifie que les résultats sont corrects.
Et vous, quelles métaphores et exemples utiliseriez-vous pour expliquer ce que sont les bouchons et les pilotes ?
Daniel Van der Zwan is a Quality Assurance Engineer specializing in sea logistics information systems. This QA professional, based in the Netherlands, recently took on an extraordinary challenge: obtaining all ISTQB certifications (27 in total)!
We are delighted to share his story with you.
Discover his new challenges, his tips for passing certifications, and the reaction of his management upon learning of his achievement!
Interview
Hightest: You obtained all the ISTQB certifications in just 4 years and 3 days. Why did you set yourself this challenge?
Daniel Van der Zwan: After I had achieved the first 2 Expert Certifications, I did the first Specialist Certification. The Syllabi for the Specialist Certifications help you get additional insights into those specific topics & contributes to obtain a wider understanding on all aspects of testing in ‘special’ areas, which I really like. Furthermore this is also helpful in the preparation for the Expert level certifications. I decided after the first Specialist to try to obtain all Certifications within 4 years.
Hightest: Now that you have obtained all the ISTQB certifications, what is your next challenge?
Daniel Van der Zwan: First of all, I want to keep my knowledge up-to-date, meaning that I want to retake the exams for updated certifications (like CTAL-TM and CT-TAE) as well as any new Certifications the ISTQB releases. If there is any time left 😉, I am taking the Certification Exams for the UNITED Syllabi of which I have already 3 Certifications. These are helpful in addition to the ISTQB.
Furthermore I am actively involved in reviewing & commenting on new/updated Syllabi for both the ISTQB and UNITED, as well that I am involved in the creation of a brand new UNITED Syllabus together with other experts (I cannot disclose the topic yet)
Hightest: Have you ever set yourself other challenges in the past? (Not necessarily in the field of testing; we can easily imagine you climbing Everest!)
Daniel Van der Zwan: Not as hard as I did with this challenge 🙂
Hightest: How do you feel now that you have achieved this record?
Daniel Van der Zwan: Proud! Especially as I noticed that it is inspiring other people to expand their knowledge as well, that is the greatest reward for me.
Hightest: If you met another person who had all the certifications, what would you infer about them?
Daniel Van der Zwan: As far as I know, I am currently the only one with all 27 ISTQB Certifications, I would welcome & support anyone who is inspired to do the same.
Hightest: What is the quality that helped you the most in passing all these certifications?
Daniel Van der Zwan: There are a few qualities you will need to have, first of all dedication & discipline, support from the people at home (it is taking a LOT of time) and last but not least, you need to be a little bit crazy…
Hightest: What is your favorite method for studying?
Daniel Van der Zwan: I have created my own approach, my 7 step principle
Step 1 – read the Syllabus
Step 2 – extract all learning objectives
Step 3 – try to formulate your own questions
Step 4 – answer them
Step 5 – check the answer with the syllabus
Step 6 – focus on the weak spots
Step 7 – take the practise exam from the ISTQB
Hightest: Which certification did you find the most difficult?
Daniel Van der Zwan: Any of the Expert Levels, these are the hardest by far.
Hightest: The most exciting?
Daniel Van der Zwan: I have to choose the same, any of the Expert Levels.
Hightest: What does your employer think of your collection?
Daniel Van der Zwan: My employer is very proud to have me on board, after achieving the 27th Certificate they have created a trophy “World Champion ISTQB Exams”
Hightest: Have you noticed that your profile has become more attractive to companies since you obtained all these certifications?
Daniel Van der Zwan: Yes I have noticed that, however as you can see in the answer on the previous questions, I have a great employer so I am happy to be part of this company.
Hightest: Are TMMi certifications on your radar? What do you think of this framework?
Daniel Van der Zwan: Yes and no, I am interested in doing these as well, however not in the short term. It looks valuable to me to start looking into this in future, I have read a lot about it in my preparation for the Expert Level Test Process Improvement. I have even developed my own model for an assessment on test process maturity which is partly based on the TMMi for the company I work for.
Hightest: You participated in the development of the new version of ISTQB Foundation. How did that go?
Daniel Van der Zwan: I have participated in reviewing & commenting on various Syllabi, for example (not limited to) CTFL4, CTAL-TM, CT-ATLaS, CT-TAE.
It is an honor to be part of these reviews. If you are interested to participate in this as well, you can check with your national ISTQB representative if they need reviewers. Of course you need to sign an NDA and have sufficient knowledge & experience.
Thank you to Daniel Van der Zwan for this interview, and good luck to everyone training for a certification!
Daniel Van der Zwan est ingénieur assurance qualité, spécialisé dans les systèmes d’information de logistique maritime. Ce QA basé aux Pays-Bas a dernièrement relevé un remarquable challenge : celui de passer l’ensemble des certifications ISTQB (27 au total) !
C’est avec beaucoup de joie que nous avons recueilli son témoignage.
Découvrez ses nouveaux challenges, ses astuces pour réussir les certifications, mais aussi la réaction de sa hiérarchie en apprenant son exploit !
Cet article en français est une traduction de notre échange ; le texte original est dans un autre article.
Interview
Hightest : Vous avez obtenu toutes les certifications ISTQB en seulement 4 ans et 3 jours. Pourquoi vous êtes-vous lancé ce défi ?
Daniel Van der Zwan : Après avoir obtenu les 2 premières certifications Expert, j’ai passé la première certification Spécialiste. Les syllabus pour les certifications Spécialistes permettent d’obtenir des informations supplémentaires sur ces sujets spécifiques et contribuent à une compréhension plus large de tous les aspects du test dans des domaines “spéciaux”, ce qui me plaît beaucoup. De plus, cela aide également à la préparation des certifications de niveau Expert. J’ai décidé après la première certification Spécialiste de tenter d’obtenir toutes les certifications en 4 ans.
Hightest : Maintenant que vous avez obtenu toutes les certifications ISTQB, quel est votre prochain défi ?
Daniel Van der Zwan : Tout d’abord, je voudrais maintenir mes connaissances à jour, ce qui signifie que je voudrais repasser les examens pour les certifications mises à jour (comme CTAL-TM et CT-TAE) ainsi que toute nouvelle certification publiée par l’ISTQB. S’il me reste du temps 😉, je passerai les examens de certification pour les syllabus UNITED, dont j’ai déjà 3 certifications. Ceux-ci sont utiles en complément de l’ISTQB. De plus, je suis activement impliqué dans la révision et les commentaires des nouvelles versions des syllabus pour l’ISTQB et UNITED, ainsi que dans la création d’un tout nouveau syllabus UNITED avec d’autres experts (je ne peux pas encore divulguer le sujet).
Hightest : Avez-vous déjà relevé d’autres défis dans le passé ? (Pas nécessairement dans le domaine des tests ; on peut facilement imaginer que vous ayez gravi l’Everest !)
Daniel Van der Zwan : Pas aussi difficile que ce défi 🙂
Hightest : Comment vous sentez-vous maintenant que vous avez accompli ce record ?
Daniel Van der Zwan : Fier ! Surtout en constatant que cela inspire d’autres personnes à élargir leurs connaissances également, c’est la plus grande récompense pour moi.
Hightest : Si vous rencontriez une autre personne ayant toutes les certifications, que déduiriez-vous à son sujet ?
Daniel Van der Zwan : Autant que je sache, je suis actuellement le seul à avoir les 27 certifications ISTQB. J’encouragerais et soutiendrais toute personne qui aspirerait à faire de même.
Hightest : Quelle est la qualité qui vous a le plus aidé à réussir toutes ces certifications ?
Daniel Van der Zwan : Il y a plusieurs qualités nécessaires : tout d’abord le dévouement et la discipline, le soutien des proches (cela prend BEAUCOUP de temps) et enfin, il faut être un peu fou…
Hightest : Quelle est votre méthode préférée pour étudier ?
Daniel Van der Zwan : J’ai créé ma propre approche, mon principe en 7 étapes :
Étape 1 – lire le syllabus
Étape 2 – extraire tous les objectifs d’apprentissage
Étape 3 – essayer de formuler mes propres questions
Étape 4 – y répondre
Étape 5 – vérifier la réponse avec le syllabus
Étape 6 – me concentrer sur mes points faibles
Étape 7 – passer l’examen pratique de l’ISTQB
Hightest : Quelle certification avez-vous trouvée la plus difficile ?
Daniel Van der Zwan : N’importe laquelle du niveau Expert, ce sont de loin les plus difficiles.
Hightest : La plus enthousiasmante ?
Daniel Van der Zwan : Je dois répondre la même chose, n’importe laquelle du niveau Expert.
Hightest : Que pense votre employeur de votre collection ?
Daniel Van der Zwan : Mon employeur est très fier de m’avoir dans l’équipe, après avoir obtenu la 27e certification, mes collègues ont créé un trophée “Champion du Monde des Examens ISTQB”.
Hightest : Avez-vous remarqué que votre profil est devenu plus attractif pour les entreprises depuis que vous avez obtenu toutes ces certifications ?
Daniel Van der Zwan : Oui, je l’ai remarqué. Cependant, comme vous pouvez le voir dans la réponse précédente, j’ai un excellent employeur et je suis heureux de faire partie de cette entreprise.
Hightest : Visez-vous les certifications TMMi ? Que pensez-vous de ce framework ?
Daniel Van der Zwan : Oui et non, cela m’intéresse aussi, mais pas à court terme. Il me semble utile de commencer à m’y pencher à l’avenir. J’ai beaucoup lu à ce sujet dans ma préparation pour le niveau Expert en Amélioration des Processus de Test. J’ai même développé mon propre modèle d’évaluation de la maturité des processus de test, en partie basé sur le TMMi, pour l’entreprise dans laquelle je travaille.
Hightest : Vous avez participé au développement de la nouvelle version de la Fondation ISTQB. Pouvez-vous nous en parler ?
Daniel Van der Zwan : J’ai participé à la révision et aux commentaires de divers syllabus, par exemple (mais pas exclusivement) CTFL4, CTAL-TM, CT-ATLaS, CT-TAE. C’est un honneur de faire partie de ces révisions. Si vous aussi vous souhaitez participer, vous pouvez demander à votre représentant national ISTQB s’ils ont besoin de réviseurs. Bien sûr, vous devrez signer un accord de confidentialité et avoir des connaissances et une expérience suffisantes.
Merci à Daniel Van der Zwan pour cet échange et bon courage à toutes les personnes qui s’entraînent pour passer une certification !
La qualité logicielle est un sujet qui peut paraître aride au premier abord. Voire, osons le dire, carrément fade.
Si vous travaillez dans le domaine, vous savez qu’il n’en est rien, et qu’il suffit d’y plonger un orteil pour découvrir un monde passionnant. Mais le plus dur, c’est de plonger ce premier orteil !
Voici donc un jeu qui vous aidera à sensibiliser un public néophyte aux enjeux de la qualité logicielle. Ce jeu se base sur la norme ISO 25010.
Durée
Entre 15 et 30 minutes (plus il y a de personnes, plus il faut s’attendre à des questions, reformulations, temps morts, blagounettes, quintes de toux, etc).
Nombre de personnes
De 1 à… beaucoup ! À partir de 4 personnes, faites des équipes de 2, 3 ou 4 personnes, c’est plus sympa.
Matériel
Post-its (un paquet de ~20 par personne ou par groupe de personnes)
Feutres (1 par personne ou par groupe de personnes)
Dessin de montagnes russes (faites-le vous-même, ne soyez pas timide !)
Si possible : tableau blanc et aimants
Du grand art
Phase 0 : préparation
Préparez le matériel.
Sur un tableau blanc, si vous en avez, dessinez un mystérieux tableau à larges colonnes.
C
Pe
Fi
Fo
S
M
U
Po
Plus tard, vous compléterez le tableau en mettant le nom des 8 facettes de la qualité logicielle définies par la norme ISO 25010 :
Compatibilité
Performance
Fiabilité
Fonctionnalité
Sécurité
Maintenabilité
Utilisabilité
Portabilité
Révisez donc bien ces 8 facettes ! Vous pouvez par exemple consulter la série d’articles qui existe sur le sujet dans le blog la Taverne du Testeur.
Phase 1 : brainstorming
Présentez le dessin de montagnes russes à votre auditoire. Puis, demandez-lui tout ce qui pourrait mal se passer dans ces montagnes russes, ou aux alentours.
Pendant un laps de temps donné (5 minutes peuvent faire l’affaire), chaque personne ou groupe de personnes écrit une idée par post-it. L’objectif de cette phase est de générer un maximum d’idées. Si vous sentez qu’une personne ou qu’un groupe se retrouve à court d’idée, vous pouvez lancer quelques pistes :
Ça peut être de gros problèmes, qui se soldent par des articles de journaux, ou bien des petits problèmes, qui vont faire passer un moment un peu agaçant à une ou plusieurs personnes.
Ça peut être des problèmes liés à l’expérience vécue sur les montagnes russes, ou des problèmes qui peuvent avoir lieu avant ou après.
Ça peut être des problèmes qui ne surviennent que dans certaines circonstances. Par exemple, des problèmes qui ont lieu lorsque le parc d’attraction est plein à craquer. Ou quand une personne effectue une action inattendue.
Ça peut être des problèmes qui ont lieu pendant l’installation, ou pendant des réparations, ou encore pendant le démontage une fois que les montagnes russes sont vétustes et doivent être remplacées.
Ça peut être des problèmes liés au lieu où se situe ce manège. Par exemple, quels sont les bâtiments qui existent déjà autour ?
Ça peut être lié au climat, à la météo…
Proposition de speech à adapter
Bonjour, c’est un plaisir d’être avec vous aujourd’hui pour parler de qualité logicielle.
Qui se sent déborder d’enthousiasme à l’idée de lire la norme ISO 25010, une des normes les plus connues dans le domaine de la qualité logicielle ? Personne ? Je comprends bien. Les normes en général ça sonne comme quelque chose d’assez ennuyeux.
Alors au lieu de parler de cette norme, on va plutôt la réécrire nous-mêmes, au moins dans ses grandes lignes.
Juste, avant de commencer, est-ce que par hasard il y a des personnes parmi vous qui ont déjà entendu parler de la norme ISO 25010 ?
OUI tout le monde -> Super, ça va être l’occasion de la revisiter !
OUI certaines personnes -> Est-ce que tu voudras/vous voudrez bien m’aider à un moment ?
NON tout le monde -> C’est bien, personne ne va s’ennuyer !
Et puisque j’ai la chance présentement de ne pas avoir d’écran sous les yeux, je vous propose également d’oublier les logiciels pour quelques instants, et de parler d’autre chose.
Est-ce que quelqu’un comprend ce que j’ai dessiné ?
Bien, et effectivement on ne va pas parler de qualité logicielle, on va parler de qualité de montagnes russes. Qui parmi vous a déjà osé monter dans des montagnes russes ?(Note de l’autrice : pas moi.)
Le système dessiné ici avec un grand talent est constitué des montagnes russes elles-mêmes, des petits chariots, du poste de contrôle, et du guichet qui permet d’acheter ses tickets.
Je vais maintenant faire appel à la facette la plus malicieuse de votre personnalité, et je vais vous inviter à imaginer TOUT ce qui pourrait mal se passer dans ce système. Vous pouvez réfléchir (par groupes de 2 ou 4, le cas échéant), en notant vos idées sur ces post-its. Vous avez 5 minutes, c’est parti !
Phase 2 : restitution de l’exercice et complétion
Une fois que le temps est écoulé, c’est le moment de la restitution !
Chaque groupe présente maintenant les idées générées au cours du brainstorming. Attendez-vous à des moments de rigolade ! Mais vous, conservez bien votre concentration ; il vous faut classer chaque idée dans le tableau. Attention, à ce stade, les noms des 8 facettes ne sont pas encore visibles.
Quelques exemples de réponses auxquelles vous pouvez vous attendre :
Facette de la qualité logicielle
Exemple lié aux montagnes russes
Compatibilité
Ce système posera problème s’il est installé à côté d’une église, parce que les cris des personnes peuvent indisposer les gens qui cherchent à se recueillir. De même si les montagnes russes sont installées à côté d’un hôpital, les malades pourraient avoir du mal à dormir, ou ressentir de la frustration à ne pas pouvoir être de la partie.
Performance
Ce système posera problème s’il tombe en panne quand il y a plus de 10 personnes dans les chariots.
Fiabilité
Ce système posera problème si le démarrage échoue 1 fois sur 2. (Ou même, une fois sur 50.)
Fonctionnalité
Ce système posera problème si les animations (par exemple les jets d’eau ou la musique) se déclenchent en décalage avec le passage des chariots.
Sécurité
Ce système posera problème si les barrières sont trop espacées et que les personnes risquent de tomber.
Maintenabilité
Ce système posera problème s’il est livré sans mode d’emploi pour les réparations, si son fonctionnement requiert une formation très complexe et spécifique, ou encore si les pièces de rechange sont introuvables dans le pays d’installation.
Utilisabilité
Ce système posera problème si les chariots sont conçus pour avancer très lentement et que personne ne s’amuse, ou que les chariots ne sont pas adaptés aux personnes de grande taille.
Portabilité
Ce système peut ne pas être adapté à tous les climats, par exemple si le métal de la structure est sensible à l’air marin.
Une fois que toutes les idées ont été classées, vous pouvez maintenant donner un sens au mystérieux tableau dessiné tout à l’heure, en le complétant. Le cas échéant, vous pouvez solliciter les personnes qui ont déclaré connaître la norme ISO 25010, pour qu’elles vous aident à compléter le tableau.
Compatibilité
Performance
Fiabilité
Fonctionnalité
Sécurité
Maintenabilité
Utilisabilité
Portabilité
Vous pouvez à présent raccrocher les wagons de la qualité logicielle ! Donnez du sens à ce tableau en demandant à votre auditoire de faire le lien entre le monde des logiciels et les 8 facettes.
Vous aboutirez probablement à des réponses similaires à celles ci-dessous :
Facette de la qualité logicielle
Exemple lié aux logiciels
Compatibilité
Un logiciel doit pouvoir coexister avec d’autres logiciels dans un même système.
Performance
Un logiciel doit pouvoir s’exécuter rapidement, même si plusieurs personnes l’utilisent en même temps.
Fiabilité
Un logiciel doit être disponible avec un minimum d’interruptions.
Fonctionnalité
Un logiciel doit pouvoir réaliser les actions qui lui ont été spécifiées. Cette facette accapare, en général, la plupart des efforts concernant la qualité logicielle.
Sécurité
Un logiciel doit sécuriser les personnes qui l’utilisent ainsi que leur matériel et, ce qui est le plus connu, leurs données.
Maintenabilité
Un logiciel doit pouvoir être maintenu au fil du temps, et bien souvent par d’autres personnes que celles qui l’ont initialement développé.
Utilisabilité
Un logiciel doit être agréable à utiliser et compréhensible par un maximum de personnes parmi celles ciblées.
Portabilité
Un logiciel doit pouvoir s’installer dans un maximum d’environnements parmi ceux ciblés.
Voilà, votre petit groupe a maintenant une idée un peu moins floue de ce qu’on veut dire quand on parle de qualité logicielle ! En complément, vous pouvez leur montrer les 8 facettes développées (merci à la Taverne du Testeur pour ce schéma).
Pour aider à mémoriser les 8 facettes, vous pouvez donner ce moyen mnémotechnique :
« Les Com–Pères dans leur Fiat Font Sécher leurs Mains en Utilisant les Portes. »
Éventuellement, pour clôturer l’atelier vous pouvez ouvrir sur d’autres perspectives :
Maintenant qu’on a ça en tête, c’est très bien, et on va pouvoir s’en servir au moment où on prévoit d’évaluer la qualité des logiciels et d’imaginer des tests. Ça fournit un cadre de pensée. Mais on peut ne pas s’arrêter là.
George Box disait « Tous les modèles sont faux, mais certains sont utiles ». La norme ISO 25010 est utile parce qu’elle permet d’avoir en tête pas mal de critères de qualité, mais elle est fausse dans le sens où elle ne prend pas en charge l’intégralité de l’expérience qu’on peut avoir de la qualité, ou des exigences qualité qui peuvent exister. Est-ce que vous voyez d’autres choses qui pourraient être ajoutées ?
(Réponse typique : qualité environnementale, mais il pourrait y en avoir d’autres !)
Conclusion
Cet exercice permet non seulement de comprendre que la qualité logicielle a plusieurs facettes, mais aussi que c’est un sujet qui nous fait poser beaucoup de questions, et que, même s’il existe une norme pour essayer d’organiser ces questions, celles-ci vont toujours au-delà.
Nourrissez votre réflexion de toutes les remarques qui proviendront de votre audience : vous découvrirez peut-être de nouveaux angles d’approche !
______________
Cet article a été écrit en langage épicène. Si vous voulez en savoir davantage, regardez notre vidéo sur le sujet !
Cet article a été écrit à 4 mains et 2 cerveaux, par Adrien Lavallière et Zoé Thivet
Dans le monde fascinant du développement logiciel, où les lignes de code s’entremêlent comme des lianes dans une jungle numérique, se cachent de redoutables prédateurs, tapis dans l’ombre, prêts à faire trébucher les QA les plus méthodiques : les bugs orthotypographiques.
Mais d’abord, qu’est-ce que l’orthotypographie, me direz-vous ? Le surnom snob de l’orthographe ? Non, pas du tout : c’est l’ensemble des règles d’usage qui concernent, non pas l’orthographe des mots, mais l’utilisation des règles de typographie, c’est-à-dire de mise en forme du texte. C’est le monde, finalement assez méconnu, des espaces, majuscules, des ponctuations, etc.
Pourquoi c’est important ?
L’attention portée à l’orthotypographie n’est pas (qu’)un délire de QA maniaques. En effet, bien que les défauts liés à cet aspect aient peu de chances d’avoir un impact fonctionnel, ils n’en restent pas moins des défauts visibles par tout le monde, très rapidement et avec peu d’efforts, au même titre que les fautes d’orthographe de manière générale.
Deux impacts possibles :
Chez les bénéficiaires de l’application : baisse de confiance envers le produit. Par une sorte d’effet de halo négatif, la perception générale de la qualité de l’application va pâtir de cette première impression.
En interne : baisse de la rigueur de la part des équipes techniques. Puisque telle ou telle maladresse orthotypographique est “passée” une fois, alors (souvent inconsciemment) il devient acceptable de manquer de rigueur sur ces aspects, et peut-être sur d’autres.
Cela ne fait pas envie. Voici donc un aperçu non exhaustif du bestiaire que l’on est amené à rencontrer lors de croisades contre ces défauts !
Les problèmes de majuscules
Que cela soit une mauvaise utilisation des majuscules en début de phrase ou sur les noms propres, les erreurs de majuscules font partie du monde de l’orthotypographie. Elles peuvent parfois avoir une incidence sur le sens de la phrase. Exemple : “Vous aussi vous aimez la Chine ?” et “Vous aussi vous aimez la chine ?” ne mettront pas d’accord les fans de voyages et de brocantes.
Elle collectionnait les lacets de chaussure de tous les pays d’Europe et pour ce faire, parcourait tous les vide-grenier qu’elle pouvait. Elle aimait vraiment la Chine.
Combo ultime : les majuscules accentuées. En effet, c’est un grand sujet de débat dans de nombreux projets informatiques ! Et comme l’explique parfaitement le site du Projet Voltaire sur son article des majuscules accentuées, c’est une controverse qui ne date pas d’hier. Plusieurs raisons expliquent cette absence. En premier lieu, les contraintes techniques : les machines à écrire ne possédaient pas ces caractères, et dans l’imprimerie traditionnelle les caractères étaient souvent indisponibles et leur composition manuelle fastidieuse. Omettre ces accents facilitait l’apprentissage. Mais aussi, certaines personnes trouvaient que les accents sur les majuscules étaient inesthétiques ou perturbaient la fluidité de la lecture.
Toutefois, les technologies modernes ont changé cette manière de penser. À l’ère de l’informatique, il est beaucoup plus simple de nos jours de mettre en place ces majuscules accentuées. En outre, ces absences d’accents peuvent créer des ambiguïtés aussi bien sur la prononciation que sur le sens d’une phrase.
Pour vous aider, voici un petit récapitulatif de ces majuscules “spéciales” (n’hésitez surtout pas à vous servir d’un pense-bête tel qu’un post-it pour ne pas trop encombrer votre cerveau) :
Caractère
Windows
Mac
À
Alt + 183 ou Alt + 0192
Verr. Maj. + 0
É
Alt + 144 ou Alt + 0201
Verr. Maj. + 2
È
Alt + 212 ou Alt + 0200
Verr. Maj. + 7
Ç
Alt + 128 ou Alt + 0199
Verr. Maj. + 9
A l’abordage !
Les problèmes de ligatures
Pour rester dans le monde des caractères spéciaux, d’autres erreurs comme l’absence de ligature typographique peuvent être remontées. Nous parlons ici des “oe” qui devrait plutôt être sous la forme “œ” (Alt + 0156) ou des “ae” pour “æ” (Alt + 0230). Ce qui permet de dire sans faute que vous avez rédigé votre curriculum vitæ ou bien que vous avez plusieurs œufs dans votre panier !
Meilleurs voeux !
Les problèmes de ponctuation
Tout comme les majuscules, les problèmes de ponctuation peuvent aussi altérer le sens de la phrase.
Exemple : Prenons l’exemple d’une phrase bien connue : “Il est tard. Et si on mangeait, les enfants ?”, cela fait de vous une personne responsable, souhaitant la survie de ses progénitures. Alors que dire “Il est tard. Et si on mangeait les enfants ?”, fait de vous… Attendez, ne bougez surtout pas – “Oui ? Allô, police ?…”
Point bonus accordé aux personnes qui font attention à la ponctuation des titres et des sous-titres ! Car en effet, ces derniers ne comportent pas de point à la fin même quand il s’agit d’une phrase complète.
Les QA disent les bugs sont très coriaces
Les problèmes d’espacements
Les problèmes d’espacement sont d’autant plus traîtres que les règles sont parfois inversées par rapport à l’anglais.
Exemple : En français, on ménage toujours une espace insécable (oui, au féminin !) avant le signe des deux points ; en anglais, jamais.
Mais une espace insécable, qu’est-ce que c’est ?
Une espace insécable, c’est une espace qui joue un rôle de “colle” entre le signe qu’elle précède et le signe qu’elle suit. C’est-à-dire que si la phrase est trop longue et nécessite un retour à la ligne, il faudra tenir compte de cette colle.
Si la phrase est “À 19 h 01, le mardi 6 février 2024, elle se dit : « Je le savais ! »”, il y a plusieurs espaces insécables, qui lient les signes suivants :
19 h 30 (deux espaces insécables : une avant et une après le “h”)
mardi 6 février 2024 (trois espaces insécables, une entre chaque mot)
dit : (une règle empirique est qu’en français, lorsque le signe de ponctuation est double, il y a une espace insécable devant)
« Je (toujours une espace insécable après le guillemet ouvrant)
savais ! » (le point d’exclamation est une ponctuation double, et il y a toujours une espace insécable avant le guillemet fermant)
Typiquement, dans un code HTML, vous trouverez des espaces insécables sous forme de .
« Oh non, ce n’est vraiment pas très beau ! »
Les problèmes de mise en forme
Le dernier type d’erreurs que nous citerons aujourd’hui est celles qui concernent la mise en forme. Et dans cette catégorie, nous pouvons inclure bon nombre d’erreurs tout comme les paragraphes mal indentés, les alignements incorrects du texte ou encore les polices de caractères inappropriées.
Bien évidemment, c’est bizarre
Conclusion
Au travers de ce bref aperçu, vous avez peut-être découvert quelques problèmes insoupçonnés. Encore une illustration que le monde de la qualité logicielle se nourrit de nombreuses spécialités et domaines d’expertise !
À (Alt+0192 ;)) bientôt pour de nouveaux articles !
Votre éthique professionnelle vous pousse à réfléchir à des solutions qui soient à la fois inclusives et durables. Et vous n’avez aucune raison de choisir entre green IT et accessibilité ! Dans cet article, nous vous proposons 4 points concrets à passer en revue pour conjuguer ces deux exigences.
NB : cet article ne s’adresse pas spécifiquement aux QA, mais aussi à toute personne impliquée dans la conception et la création de produits numériques !
1. Parlez-en à un stade précoce des projets
L’accessibilité et la performance énergétique partagent un point commun : elles ne concernent pas les fonctionnalités de ce que vous allez offrir (le “quoi”), mais plutôt les caractéristiques de la manière dont votre solution est conçue et fonctionne (le “comment”).
Afin de maximiser vos chances de succès, intégrez ces problématiques dès le cadrage de vos projets, pour établir clairement les objectifs et identifier les ressources nécessaires.
Lors de la conception du produit, faites en sorte que ces sujets soient incontournables. Par exemple, lors de la définition des objectifs initiaux du projet, vous pouvez spécifier des critères d’accessibilité mesurables, tels que la conformité aux WCAG (Web Content Accessibility Guidelines). Pour la performance énergétique, cela peut être un score Ecoindex à viser.
Y penser dès le début est susceptible d’orienter les choix de certaines solutions technologiques, mais aussi de vous faire gagner du temps.
2. Pensez “Less is more”
L’utilisation de produits numériques peut être pénible pour une personne porteuse d’un handicap. Proposer un nombre restreint de fonctionnalités, avec un contenu qui va droit au but et sans fioritures inutiles, représente une réelle valeur ajoutée. D’ailleurs, comme presque tout ce que vous proposerez pour favoriser l’accessibilité, cela profitera également aux populations non porteuses de handicap ! Une expérience plus fluide est un atout pour l’ensemble de votre cible.
Moins de fonctionnalités signifie moins de requêtes envoyées aux serveurs, moins de code à maintenir… Et cela représente donc également un gain en termes de performance environnementale.
Faites l’expérience pour vous entraîner. Consultez vos sites web préférés et demandez-vous : qu’y a-t-il en trop ? Qu’est-ce qui m’est réellement utile ? Vous en ferez vous-mêmes le constat : au quotidien, vous nagez dans les images inutiles (non informatives) et dans des animations qui ne font rien d’autre que vous ralentir. Et aussi, dans les features qui ont pris un temps fou à développer, mais qui ne correspondent tout simplement pas à votre usage.
3. Texte > Image > Vidéo
On dit qu’une image vaut mille mots. Cela signifie communément qu’une image peut transmettre une information beaucoup plus facilement qu’un texte. C’est, en effet, parfois vrai.
Mais d’un point de vue green IT, on pourrait dire aussi qu’une image “coûte” mille mots… ou beaucoup plus, en fonction de la taille de l’image et de sa résolution !
Et c’est sans parler des vidéos, particulièrement énergivores.
Un simple texte est le support qui est à la fois le plus accessible et le plus performant d’un point de vue environnemental.
Un texte peut être lu “tel quel”, ou bien être agrandi d’un simple clic, ou encore être lu par synthèse vocale ou même en braille.
Il peut être rapidement mis à jour, ce qui réduit à la fois l’empreinte énergétique et le budget de maintenance.
Il se charge beaucoup plus rapidement que toute autre ressource.
Cela ne veut pas dire que les images et les vidéos sont à bannir, mais il faudra veiller à ne conserver que celles qui apportent le plus de valeur ajoutée, et à optimiser leur compression.
4. Les valeurs d’abord, les actions ensuite
La performance énergétique et l’accessibilité ne sont pas des sujets anodins. Loin d’être de simples concepts techniques, ce sont des engagements envers un avenir meilleur. Affirmer leur importance au sein d’une organisation, en les portant au rang de valeurs, donne une signification décuplée à la démarche… et certainement aussi, beaucoup plus d’enthousiasme aux équipes, à l’heure où une grande part de la population souffre d’éco-anxiété et d’un sentiment général de perte de sens.
Cet article a été écrit dans le cadre de notre participation à la commission NID (Numérique Inclusif et Durable) de l’organisation OPEN NC. Il bénéficie de la précieuse contribution de Xavier Liénart (MSI), dont la relecture a permis d’enrichir le fond de l’article.
En 1987, David Gelperin et Bill Hetzel publiaient l’article scientifique The growth of software testing dans la revue Communications of the ACM. Un article dans lequel, regardant en arrière, ils définissaient différents seuils où le métier du test a évolué.
Un article de référence
Quel est donc ce découpage temporel ?
Première époque, orientée débogage
Les processus de test ne sont pas traités en tant que tels ; les tests sont effectués de manière ad hoc essentiellement, et les succès ne sont guère reproductibles puisqu’ils dépendent avant tout du bon vouloir et du talent d’individus isolés.
Deuxième époque, orientée démonstration
Pour résumer, on teste pour prouver que le logiciel fonctionne.
Troisième époque, orientée destruction
Ca fait peur, non ? Cela veut dire tout simplement que cette période est marquée par le cliché (toujours vivant) des QA qui sont là pour “tout casser” ! Même si, on le sait, le test logiciel met plutôt en lumière ce qui est déjà cassé.
Quatrième époque, orientée évaluation
L’activité de test donne lieu à des métriques. On la suit de manière formelle.
Cinquième époque, orientée prévention
L’objectif principal des tests est d’éviter en premier lieu l’apparition des anomalies, et ce grâce à des méthodes statistiques.
Les suites de cet article
Ce découpage en périodes historiques a fait date ; il est toujours mentionné notamment dans les documents relatifs au modèle TMMi. En effet, les 5 niveaux de maturité TMMi font écho aux 5 époques mentionnées par les auteurs de l’article.
Mais, bien que ce soit fort intéressant, ce n’est pas le sujet le plus croustillant de cet article ! 😃
En pratique, comment testait-on jadis ?
Une partie un peu moins connue de cet article fait en effet référence à un sondage diffusé à l’occasion de la 4ème conférence internationale sur le test logiciel, qui s’est tenue à Washington en 1987. Préparez-vous à un voyage dans le temps !
Résultats du sondage en anglais
Traduction du sondage en français
Un historique des défauts trouvés pendant les tests est maintenu : 73 % oui / 16 % parfois
Une personne est désignée en tant que responsable du processus de test : 65 % oui / 13 % parfois
Un plan de test décrivant les objectifs / l’approche est requis : 61 % oui / 29 % parfois
Le test est une activité systématique et organisée : 61 % oui / 30 % parfois
Des profils de test réalisent des tests système à temps plein : 62 % oui / 19 % parfois
Le test est séparé du développement : 60 % oui / 20 % parfois
Les tests doivent être rejoués lorsque le logiciel change : 51 % oui / 35 % parfois
Les tests sont conservés et maintenus en vue d’une utilisation ultérieure : 51 % oui / 28 % parfois
Les spécifications et la conception des tests est documentée : 48 % oui / 36 % parfois
La procédure de test est documentée dans le manuel des standards : 45 % oui / 15 % parfois
Un historique des tests joués est maintenu : 42 % oui / 35 % parfois
Le temps consacré aux test est suivi : 40 % oui / 30 % parfois
Les documents de test font l’objet d’une revue par les pairs formelle : 31 % oui / 29 % parfois
Des profils de test réalisent des tests d’intégration à temps plein : 24 % oui / 24 % parfois
Les coûts des tests sont mesurés et suivis : 24 % oui / 19 % parfois
Des formations en test sont fournies périodiquement : 22 % oui / 26 % parfois
Les résultats des tests font l’objet d’une revue par les pairs formelle : 20 % oui / 31 % parfois
Les utilisateurs et utilisatrices ont une forte implication dans les activités de test : 8 % oui / 39 % parfois
Les tests sont créés avant le développement : 8 % oui / 29 % parfois
Une mesure de la couverture de code est requise : 5 % oui / 16 % parfois
Il faut garder à l’esprit que les personnes ayant répondu au sondage participaient à un congrès sur le test logiciel. Elles avaient donc a minima un intérêt pour le sujet. Cet état des lieux représente donc certainement les pratiques des entreprises les plus à la pointe dans le domaine à l’époque !
Tout en reconnaissant que les pratiques de 1987 avaient aussi, potentiellement, des atouts que nous avons peut-être perdu en cours de route, ces résultats de sondage ne sont-ils pas rafraîchissants ?
De retour au XXIème siècle, comment vous sentez-vous après avoir fait ce petit saut dans le passé ?
Et surtout, d’après vous, lesquelles de nos pratiques sembleront désuètes aux QA de 2059, dans 36 ans ?
Le voyage dans le temps n’est pas fini et nous devons continuer de perfectionner nos pratiques ! 😃
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.
Image générée à l’aide de l’IA Midjourney symbolisant l’aspiration de données
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 :
Qu’est-ce que la cybersécurité et pourquoi est-elle importante pour les entreprises et les particuliers ?
Quelles sont les principales menaces en matière de cybersécurité auxquelles les entreprises et les particuliers sont confrontés ?
Comment les entreprises et les particuliers peuvent-ils se protéger contre les cyberattaques ?
Quels sont les outils et les technologies les plus efficaces pour la cybersécurité ?
Comment les utilisateurs peuvent-ils se protéger contre les attaques de phishing et les escroqueries en ligne ?
Comment les entreprises peuvent-elles sensibiliser leurs employés à la cybersécurité et promouvoir des pratiques de sécurité ?
Comment lacybersécurité a-t-elle évolué au fil des ans et comment est-elle susceptible de changer à l’avenir ?
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 :
