La QA : pourquoi c’est indispensable à votre projet ?

Que vous soyez un testeur averti ou un simple curieux, cette page à vocation à présenter de manière globale ce que représente un pôle QA (Quality Assurance) au sein d’une entreprise du numérique.

Comment testons-nous chez Amiltone ? Avec quelle méthodologie et pourquoi avons-nous fait ces choix ? Pourquoi les tests sont-ils indispensables, que vous réalisiez un logiciel de comptabilité ou un jeu vidéo ? Vous aurez la réponse à ces questions sur cette page !

Quality Assurance tous risques ! 

La Quality Assurance (QA) désigne les procédés mis en place au sein d’une société de bien ou de service en vue de vérifier la conformité des éléments produits au cahier des charges initial.

Dans le secteur de l’IT et du développement logiciel, la QA désigne plus spécifiquement les processus mis en place par les testeurs afin de mesurer, analyser et qualifier lesécarts qui peuvent survenir lors du développement d’une application. Si le développement mobile vous intéresse, n’hésitez pas à lire notre article sur le sujet !

Le métier d’ingénieur test et validation regroupe lui aussi de nombreuses facettes, qui interviennent tout au long du développement des applications, au sein des équipes travaillant en agilité – scrum. 

Pôle indépendant mais qui travaille avec tous les autres intervenants d’un projet, nos testeurs vont tordre votre projet dans tous les sens et lui faire subir les pires contrariétés possibles. Le but ? Détecter un maximum d’erreurs potentielles et les anticiper pour que l’utilisateur final de votre application puisse pleinement profiter de son expérience.

Mais si avant toute chose à mise en place d’un projet vous intéresse, jetez un œil à notre infographie et montez votre projet brique par brique !

Des développements optimisés, des itérations plus efficaces, des anomalies moins nombreuses… La QA est un pôle indispensable du développement logiciel web et mobile.

Anomalies / écarts / bugs ?

Vous entendrez sur cette page les mentions d’erreurs, d’anomalies ou d’écarts, mais jamais la mention de bugs. Pourquoi cela ?

En QA testing, on préfère toujours éviter les mentions de bugs, qui renvoient à une erreur d’exécution dans le code informatique et sont donc péjoratifs. On préfère donc les termes écarts ou anomalies pour relever des incohérences entre le cahier des charges et le livrable.

Cela est d’autant plus vrai que parfois les besoins initiaux évoluent au fil du temps (car ils pouvaient être mal formulés initialement ou bien, ils ont évolué au contact des tests).

Les différents tests QA 

une des tâches définissant le mieux le rôle d'un QA testeur sera… le test ! Ils sont nombreux, pointus et chaque test à un but précis. Des objectifs qu’ils atteignent grâce à des procédés qui leurs sont propres également. De plus, si chaque test est unique, ils sont en général regroupés en 2 catégories : Les tests fonctionnels et non fonctionnels. 

La différence est simple : les tests fonctionnels portent sur une fonctionnalité précise d’un produit. Les tests non fonctionnels portent sur l’écosystème associé.

• Les tests fonctionnels vérifient que chaque composant de code réponde correctement lorsqu’il est sollicité. Le résultat obtenu doit être conforme au cahier des charges.

• Les tests non fonctionnels sont globaux. Ils se focalisent sur les comportements généraux de l’application : est-elle performante, robuste, sécurisée ?

Les tests fonctionnels : 

Tests unitaires 

C’est l’un des premiers tests effectué au cours d’un projet. Ils sont souvent effectués par le développeur lui-même, après avoir codé tout ou partie d’une fonctionnalité. 

Le test unitaire vérifie le code associé à cette fonctionnalité pour établir que le résultat attendu est au rendez-vous ! Il est effectué dans un environnement fermé.

C’est-à-dire qu’il est isolé des autres fonctionnalités (ce sont d’autres types de tests qui vérifieront, plus tard, son implémentation au sein d’un environnement plus complexe avec d’autres fonctionnalités). Un test unitaire répété plusieurs fois doit aboutir au même résultat. 

Intégration

Les tests d’intégration consistent à s’assurer que l’intégration de diverses fonctionnalités au sein d’un même bloc de code soit fluide et non sujette à la création d’écarts ou d’anomalies. 

Les fonctionnalités ont auparavant toutes été testées une par une pour garantir la solidité du code. 

Les tests d’intégrations sont réalisables en interne auprès de vos équipes. Il est possible d’externaliser cette pratique dans le cadre d’une Tierce Recette Applicative (voir paragraphe dédié ci-dessous).

D’ailleurs, si l’externalisation est un sujet qui vous pose question, nous ne saurons que trop vous conseiller de lire notre ebook sur l’externalisation des projets numériques et ses 5 idées à oublier d’urgence !

Systèmes

Il s’agit d’un test visant à garantir qu’une solution logicielle, dans sa globalité, est fonctionnelle. Il faut s’assurer que le logiciel fonctionne de son lancement à son arrêt. Par dessus tout, il faudra vérifier son comportement sur les appareils sur lesquels l’application fonctionnera.

Plus qu’ailleurs, ces tests doivent être menés en indépendance des équipes de développement, afin d’éviter des rapports biaisés et subjectifs. 

Acceptation 

Les tests d’acceptation sont l’étape de validation de la solution auprès du client. En clair : est-ce que la solution finale proposée répond aux spécifications techniques du cahier des charges initial ?

Si la réponse est oui, il y a peu de chances que votre utilisateur final soit déçu. Oh yeah !

Les tests non fonctionnels 

Robustesse

Comme son nom l’indique, ce test permettra de vérifier la solidité (ou établir la fragilité) de votre application ! Comment ? En procédant à toutes sortes d’essais !

Il y a des tests qui sont plus éloignés des fonctions ou du but initial de l’application. Ils permettent d’expérimenter un grand nombre de cas “extrêmes”, à même de mettre l’application en difficulté. Cela permettra de déceler ses potentielles faiblesses.

Performance 

Les tests de performance sont, comme leur nom l’indique, des indicateurs sur la capacité de votre application à être “performante”. C’est-à-dire ? Rapide, fiable et capable de gérer un nombre important de données de manière simultanée. 

Pour conclure, nous pouvons avancer qu’ils sont notamment importants dans un cadre de forte concurrence où faire moins bien que les autres serait rédhibitoire. 

Montée en charge

Une fois terminée et livrée, votre application doit être en mesure de supporter un nombre croissant d’utilisateurs. Votre produit doit être efficace et fluide, aussi bien avec 2 utilisateurs que 2000. Mais alors, comment anticiper le nombre d’utilisateurs finaux ?

C’est complexe, car un grand nombre de facteurs entre en jeu (accessibilité de l’application, promotion éventuelle… ). La seule limite de votre application sera la taille du marché de vos utilisateurs cibles…

Votre application doit absolument rester fonctionnelle et performante. Quand bien même un nombre d’utilisateurs plus important que prévu l’utilise.

Compatibilité plateforme

Les tests de compatibilité plateforme vont s’assurer que votre application respecte les bonnes pratiques des environnements sur lesquels elle sera installée. Sans quoi, elle ne sera pas accessible aux utilisateurs.

Ils sont notamment essentiels pour définir si votre application peut être lancée sans les droits d’administrations, si elle répond aux obligations des stores mobiles ou si le protocole d’installation/désinstallation est sécurisé !

Ergonomie 

Les tests d’ergonomie sont capitaux pour s’assurer que les interfaces de votre application répondent aux bonnes pratiques et donc que l’expérience utilisateur (UX) aura été pensée avec succès. Et pour ça, on a écrit un article sur comment penser et concevoir son expérience utilisateur, de rien !

Plus subjectif, il faudra s’attarder avec empathie sur le ressenti de l’utilisateur final au contact de votre application. Mettre en place ces tests est indispensable pour s’assurer d’une UX optimale ! On vous dit tout dans un de nos article à ce sujet : alors osez l’expérience utilisateur !

Interface graphique 

Similaire au test d’ergonomie, sauf que ceux-ci se concentrent sur l’UI (User Interface, interface utilisateur) au lieu de l’UX.

De plus, il conviendra de respecter les bonnes pratiques. Vos interfaces doivent être claires et lisibles. Elles ne doivent pas perdre pas votre utilisateur final !

Sécurité 

La sécurité est un enjeu essentiel pour une application. Il est important de définir la sécurité comme une exigence non fonctionnelle au sein même des spécifications !

En effet, il faudra établir différents niveaux de sécurité interne à votre application. Définir et tester les protocoles d’accès, réaliser des tests d’intrusion internes et externes restent importants…

La sécurité ne se pense pas comme un ajout à la fin de la conception. C’est primordial, car elle se construit bel et bien tout au long du développement ! 

Installation   

Les tests d’installation, comme leur nom l’indique, servent à s’assurer que les protocoles d’installation soient clairs, efficaces, précis et compréhensibles !

Votre application réagit-elle de la même manière quel que soit le téléphone ou la tablette ? Peut-elle être facilement déployée ? Ces tests garantissent le bon démarrage de l’application. Néanmoins, il ne faut pas négliger l’analyse des supports d’installation, pour s’assurer de l’absence de virus. 

Configuration

Similaires aux tests d’installation, les tests de configuration garantissent que votre application se lance de manière fiable et claire sur son support !

Face au renouvellement de plus en plus fréquent des devices, il faut que votre application soit toujours fluide et pertinente ! Et ce, quel que soit le support d’affichage des interfaces !  

Les Tests de non régression sont communs aux tests fonctionnels et non fonctionnels. Ils sont tout de même plus proches des premiers cités. Leur but est d’éviter les effets de bord !

C’est-à-dire, vérifier que l’agrégation des différents blocs de code qui composent chaque fonctionnalité ne s’entrechoquent pas. Ce qui rend votre application moins performante voire inutilisable ! 

Ils représentent généralement la dernière étape de la QA. Donc une petite partie du temps sur la totalité d’un projet. Ces tests sont indispensables pour détecter des erreurs potentiellement fatales pour votre app. 

“Les tests ont un effet collatéral doublement positif : C’est une preuve factuelle pour vous que les livrables sont performants. Ils démontrent, par leur caractère poussés et exhaustifs, notre implication et l’attention portée à votre projet. “

– Benoit. W. expert QA chez Amiltone

2 – QA / QC : Quelle est la différence ?

Si vous avez aperçu le terme de QA, il y a de grandes chances que son acolyte QC ait également croisé votre regard. Alors, quelle est la différence entre ces deux notions ? 

QA est l’acronyme de Quality Assurance. Il s’agit de contrôler l’ensemble du processus de production : respecte-t-il nos exigences de qualité ? Toutes les parties prenantes ont été impliquées ? Respecte-t-il la méthode Agile ? 

Au-delà des vérifications, le pôle QA garantit le respect de nos valeurs et la qualité générale de nos productions ! 

Après avoir identifié une erreur de processus, le pôle QA doit remonter à l’origine du problème. Ensuite, il procède aux modifications nécessaires pour que l’anomalie ne se reproduise plus ! 

QC est l’acronyme de Quality Control. Nous nous assurons que les résultats obtenus sont en accords avec le cahier des charges !

Les features sont testées une par une. Un nouveau sprint est ensuite lancé. Il se répète jusqu’à ce que le résultat soit conforme au cahier des charges.

Si les deux métiers sont complètement différents, ils sont liés. Investir sur la QA (ou regarder notre offre en Tierce Recette Applicative (TRA)) permettra d’améliorer vos processus de production et de diminuer les coûts de QC. 

3 – QA Tests : les process !

Il existe de nombreuses manières de tester des applications, chacune ayant ses forces et faiblesses, mais toutes ont un intérêt ! 

Navigateurs et devices « réel » vs émulateurs :  2 méthodes complémentaires 

Pour vérifier que votre application marche sur un smartphone, il existe deux moyens : la tester sur un émulateur (une interface de smartphone simulée sur un ordinateur) de smartphone, sur un ordinateur ou… l’installer et la tester directement sur un smartphone ! Pourquoi ces deux méthodes ? 

Il est absolument nécessaire de faire des  tests sur des versions de système d’exploitation différentes, des tailles et des résolutions d’écrans qui varient, des processeurs de puissances inégales…

Mener ces tests sur un émulateur permet d’obtenir des résultats plus rapides et robustes que sur des tests manuels avec de vrais devices. En revanche, les émulateurs ont également la capacité de simuler précisément des conditions d’anomalies remontées par le client par exemple. 

Mais alors, quels intérêts des tests sur un smartphone “physique” dans ce cas ? 

Le nombre et la fonction des périphériques du smartphones vont grandement varier entre les modèles. De plus, cela va multiplier les conflits potentiels entre l’application et les périphériques. Ces données sont extrêmement précieuses pour optimiser au mieux votre application !

Il est quasiment impossible que votre application soit disponible partout. En effet, c’est la faute à une très grande variété de modèles de smartphone différents, en termes de puissance, d’affichage… etc. 

Il existe un autre intérêt à effectuer vos tests sur des devices concrets… En effet, comme le dit notre expert Benoît : 

L’avis de notre expert

Un Smartphone, c’est vivant !

Ce n’est un secret pour personne : un téléphone effectue en permanence tout un tas d’opérations et il n’est pas à l’initiative d’une bonne partie d’entre elles : mises à jour d’applications, notifications, appels, transfert de données, recherche de réseau…
Il n’est pas possible de reproduire à l’identique le véritable comportement d’un smartphone sur émulateur.

Notre flotte représente les modèles de smartphones “porte-étendard” (Flagships) de chaque marque. Cela représente généralement les téléphones les mieux vendus sur le marché. De plus, celle-ci est évaluée tous les six mois afin de correspondre au mieux aux appareils présents sur un marché que l’on sait très actif.

QA & Final User : A love story 

Pas de QA sans Final User ! Et oui, chaque test effectué, chaque nouvelle itération de développement doit garder en ligne de mire son objectif implicite : répondre aux attentes, conscientes ou non de l’utilisateur final ! 

Cela peut sembler de l’ordre du détail, mais une fonctionnalité de smartphone peut passer de superflue à essentielle selon les usages de votre utilisateur !

C’est pour ça qu’une bonne connaissance à la fois du milieu applicatif et de vos utilisateurs finaux est un avantage indéniable dans la conception d’une app ! Nous avons l’habitude de dire que la QA aide le client à bâtir ses exigences.

Notre conception est que la QA n’est pas juste “l’inspection” d’une application à la fin des développements pour vérifier sa conformité aux spécifications techniques, il s’agit d’un accompagnement en vue de construire une application qui réponde à vos exigences et à celles de vos utilisateurs finaux, tout en restant fidèle à votre image et vos valeurs ! 

Une interview de vos Final Users, pourquoi c’est une bonne idée ?

Quand c’est possible et faisable, nous demandons à rencontrer les utilisateurs finaux de l’application.

Pourquoi ?

En faisant preuve d’empathie et en essayant de comprendre les usages et pratiques de vos utilisateurs finaux, nous sommes plus à même de concevoir les interfaces qu’ils vont utiliser ! Cette personnalisation des interfaces en fonction des attentes (conscientes ou non !) de vos utilisateurs finaux est, en partie, ce qui rend une application ergonomique et agréable d’usage !

Il faut également porter une attention particulière aux freins et frustration chez les utilisateurs, car il est généralement possible d’y répondre via des modifications de l’UX. 

Pas de QA toxique grâce au principe du pesticide 

Vous avez sûrement déjà entendu l’adage “Les antibiotiques, c’est pas automatique” ? Le principe du pesticide est assez similaire !

A l’instar d’un désherbant, qui perdra en efficacité à mesure qu’il sera utilisé sur une parcelle agricole, plus un testeur travaille en étroite collaboration avec l’équipe de développement sur un projet, plus il sera enclin à accepter certains écarts. Qui n’a jamais entendu le fameux “ça, c’est historique !” sur son projet, par exemple ?

De plus, et souvent de façon inconsciente et naturelle, un testeur peut s’acclimater à la manière de coder de ses collègues, ou au rendu visuel d’un projet, et donc être plus perméable aux erreurs.

Comment résoudre ce problème ? Il faut absolument garantir un regard neuf sur les tests et plans de test à intervalle régulier. En conséquence, nous avons installé un système d’échange ponctuel de projet entre les testeurs. Afin que, régulièrement quelqu’un n’ayant pas ou peu travaillé sur le projet puisse apporter un regard extérieur à ce qui a été produit.

QA Neutre : une obligation ! 

La neutralité du pôle QA est un prérequis indispensable pour obtenir des résultats fiables ! Premièrement, notre pôle est le garant du respect des bonnes pratiques au sein des systèmes d’information mais aussi de la conformité de votre application.

Il est important d'en tenir compte des exigences modernes du développement. Garantir l’indépendance du pôle QA est primordial ! Les retours doivent êtres décorrélés des deadlines des développeurs, cela évite de passer à côté d’anomalies majeures qui peuvent avoir de lourdes conséquences ! Y compris, par exemple, sur la commercialisation de votre application. 

La QA en Tierce Recette Applicative (TRA) 

QA et TRA, ça fait beaucoup de lettres, mais qu’est ce que ce terme technique ? La Tierce Recette Applicative signifie que nos experts techniques viennent renforcer vos équipes le temps de votre ou vos projets. Nos experts certifiés étant disponibles auprès de vos équipes et formés à la méthode agile, cette méthode comporte de nombreux avantages :

• Des équipes d’ingénieurs QA qui garantissent la conformité des livrables logiciels grâce à un cahier de recette établi conjointement. 

• Nos testeurs sont à même d’être force de proposition. En effet, ils se forment sur vos métiers pour développer leur expertise et leur réactivité.  

• La conservation de la maîtrise des coûts des recettes. 

• Vous conservez la maîtrise sur l’avancement du projet et la gestion des contraintes de planning. 

Profitez de l’expertise d’Amiltone directement dans vos équipes !

N’hésitez pas à consulter notre site internet pour plus d’informations sur nos processus de Tierce Recette Applicative !

4 – QA & Test Automation : attention à l’abus !

La Test automation consiste à automatiser au maximum divers tests, afin de les rendre plus rapides et fiables. Mais l’automatisation n’est pas la solution miracle parfois prônée à outrance. 

Pourquoi automatiser les tests ?  

Si l’automatisation des tests à la côte, ce n’est pas pour rien ! Automatiser les tests, c’est enlever le facteur humain pour que ceux-ci soit exécutés par une machine préalablement paramétrée par un testeur. Un facteur humain moins présent, ce sont des économies réalisées ! 

Automatiser les tests, c’est concevoir des scripts qui s’exécutent de manière autonome et dont les résultats sont comparables aux versions antérieures de votre projet. La machine pouvant faire tourner des tests toute la nuit de manière continue en conservant un haut degré de précision.

De plus, le facteur humain est beaucoup moins sollicité et cela entraîne donc une diminution des coûts des tests. Il est important de noter que l’automatisation des tests de votre projet exige un travail de préparation de scripts chronophage. Cependant, une fois votre script conçu, vous pouvez le réutiliser à chaque fois que cela est pertinent ! 

Des tests automatisés en continu semblent donc être la méthode la plus adaptée. Pourquoi ? Car même si un investissement fort est nécessaire au début pour paramétrer les nombreux scripts, vous en sortirez gagnant car ceux-ci finiront par vous faire gagner du temps. Plus fiables, plus rapides et plus efficaces, ils seront forcément un avantage sur le long terme pour vos projets.

Eh bien pas forcément… 

QA & Amiltone : notre méthode 

Nous optons pour une approche hybride pour nos tests ! En effet : nous ne prônons pas le 100% automatique. Pourquoi ? Car nous nous appuyons sur l’expertise et les compétences techniques de nos testeurs en premier lieu. 

Le choix de l’automatisation n’est pas porté sur des features ou fonctionnalités particulières, mais sur des zones critiques définies avec le client. Ces zones à risques, en général pas plus de 20 % des fonctionnalités, feront l’objet de tests automatisés conçus et supervisés par nos équipes.

Il est en effet prouvé que le principe de Pareto s’applique très bien aux tests informatiques. En moyenne, 20 % des features causent 80% des anomalies, et c’est sur ces zones critiques que s’applique l’automatisation !

Pourquoi ne pas tout automatiser ? Un processus d’automatisation de test exige une phase préparatoire conséquente. Il faut analyser les résultats et coupler cela à la maintenance de scripts. Cela peut s’avérer très chronophage, rendant caduque l’intérêt initial d’automatiser les tests.

De plus, nous ne recommandons pas l’automatisation sur mobile, pour la raison que nous évoquons dans nos process : les smartphones “vivent” et un environnement simulé ne pourra pas pleinement rendre compte des multiples et complexes interactions qui surviennent au sein de l’écosystème d’un device !

Seule exception à cette règle ? Des cas particuliers où votre application fonctionnera en environnement fermé, que vous maîtriserez à 100%. Finalement, coupler automatisation et supervision technique est une méthode robuste, qui permet de profiter des forces de chaque approche. 

5 – Le QA Tester et quelques-uns de ses outils 

Voici une présentation non exhaustive des outils de notre pôle QA. Ceux-ci évoluent ou s’adaptent en fonction de votre projet, afin que les tests soient toujours pertinents et adaptés à votre projet. 

Test Automatique

Sélénium 

Très populaire, Sélénium est un framework développé en Java. De plus, il peut notamment interagir avec chrome et firefox.

Attention : Java ≠ Javascript !

Cependant si les frameworks Javascript vous intéressent, rendez-vous sur notre article : Le petit top des frameworks Javascript.

Test de charge

LoadRunner 

Cet outil est, entre autres, capable de prendre en charge une très large gamme de technologies et de protocoles. 

WebLoad

Flexible et scalable, cette solution est capable de simuler un grand nombre de scénarios.  

Gestion de test

Squash 

Cette solution de test est open source. En bref, elle s’adapte facilement aux projets, même les plus exigeants. 

Bugtracking

JIRA 

JIRA est à la base (et reste encore aujourd’hui) un outil de bug tracking particulièrement efficace grâce à la précision de ses rapports. De plus, il assure aujourd’hui la connexion entre toutes les équipes impliquées dans le développement.

6 – Certifié QA, est-ce utile ? 

Acronyme de International Software Testing Qualification Board, l’ISTQB distribue des certifications garantissant la bonne maîtrise des principes du testing. En attendant, est-ce vraiment utile ? (Spoiler : oui !) 

Qu’est-ce qu’apporte une certification QA de l’ISTQB ?

Un Mindset

L’état d’esprit du testeur n’est pas inné, il s’apprend ! C'est-à-dire ? Comment s’intégrer au sein d’une équipe agile, comment cloisonner et décloisonner les tâches pour gagner en efficacité... Une  certification ISTQB vous donne ces outils. 

Une Méthodologie universelle

Connue à l’international, la méthode de test de l’ISTQB apporte des garanties quant à la maîtrise des termes et processus techniques. Bien qu'elle ne soit pas indispensable, elle est un plus indéniable. 

Des échanges avec des professionnels

La certification vous donnera, entre autres, l’occasion d’échanger avec des professionnels reconnus, qui n'hésitent pas à adapter les cours théoriques aux exemples concrets que vous pourrez rencontrer dans des phases de tests. Constructifs et avec une réelle visée pratique, ces échanges ne pourront que faire progresser vos tests ! 

Une connaissance des termes techniques 

Si des glossaires existent, il est toujours mieux d’avoir des professionnels à même d’expliquer les logiques qui sous-tendent les concepts du test. En tout cas, c'est très utile en cas de collaboration des ingénieurs QA avec plusieurs équipes sur des projets d’envergure. 

Consultez le site officiel de l’ISTQB pour en savoir plus !

Les QA Certifs chez Amiltone 

La Fondation ISTQB certifie la totalité de nos testeurs. Ce premier niveau de certification vient attester de 4 jours de formation et aborde les fondamentaux jusqu’aux outils de test, en passant par l’implication d’un QA testeur au sein des cycles de production d’une application. 

Certains de nos experts sont titulaires d’une certification Testeur Agile. C’est-à-dire ? Celle-ci garantit que le certifié peut s’intégrer au sein des processus agiles et des rituels d’équipes, ce qui facilite les relations avec les développeurs ! 

Faut-il connaitre du code informatique pour être testeur QA ? 

C’est une question qui revient souvent auprès des personnes intéressées par la QA ! 

Il n’est pas indispensable d’être un expert. Néanmoins, il faut de solides connaissances en langages de programmation afin d’être à même de remonter les bugs efficacement à l’équipe de développement. 

De plus, de nombreuses connaissances annexes sont également nécessaires. Pour être un testeur accompli, il faut des protocoles et des règles de sécurité en informatique. Mais aussi en télécommunications, il faut une bonne maîtrise des systèmes d’exploitation, par exemple.  

A l’instar des autres métiers de l’informatique, les outils et technologies évoluent rapidement ! Il faut mener une veille attentive pour être toujours à jour !

Toutes nos réalisations sont passées dans les mains de nos experts QA ! Si vous souhaitez en savoir plus ? Peut-être sur Amiltone ? Ou la QA au sein d’Amiltone ? 

Contactez-nous !