Tester des objets connectés : retour d’expérience de Valentin et Florian

8 avril 2026

Photo de Valentin et Florian, collaborateurs SSID chez leur client

Tester une application, c’est déjà un sacré travail. Mais quand il faut en plus manipuler des objets connectés, gérer des connexions instables et comprendre le comportement de devices parfois capricieux, le métier de QA prend une toute autre dimension. Valentin et Florian partagent leur quotidien au cœur du test d’objets connectés, entre terrain, imprévus et apprentissage permanent.

Qui êtes-vous et quel est votre parcours ? 

Florian
“J’ai 34 ans et je suis Test Analyst depuis 9 ans. J’ai travaillé pendant 7 ans chez Inetum, exclusivement dans le secteur bancaire, avant de rejoindre SSID il y a 2 ans. Mon parcours s’est donc longtemps concentré sur des applications métiers complexes, fortement réglementées. Aujourd’hui, chez mon client, je découvre un univers totalement différent avec les objets connectés.

Avant d’être testeur, j’étais assistant d’éducation TICE (Technologies de l’Information et de la Communication pour l’Enseignement), avec une forte appétence pour l’informatique.”

Valentin
“J’ai 27 ans. J’ai travaillé pendant 8 ans dans la restauration avant d’entamer une reconversion professionnelle vers le test logiciel il y a bientôt 3 ans. J’ai suivi une formation ISTQB, puis en rejoignant SSID, j’ai principalement évolué sur des projets e-commerce.

Je travaille depuis 5 mois chez mon client actuel, où je découvre progressivement le test d’objets connectés. »

En quoi consiste votre mission chez votre client ?

Nos missions sont globalement similaires, avec toutefois des différences selon les fonctionnalités et les objets que nous testons.

Nous intervenons sur :

  • les nouvelles mises à jour de l’application client,
  • l’ajout de nouvelles fonctionnalités,
  • les correctifs de bugs,
  • l’évolution des paramètres,
  • les nouveaux modes de connexion,
  • l’intégration de nouveaux objets connectés.

Les tests portent à la fois sur l’application mobile et sur les objets physiques.

Valentin
« J’ai travaillé sur la fonctionnalité de changement de contrat. Il s’agissait d’un module de conseil dans l’application client permettant de comparer son contrat électricité avec d’autres offres fournisseur pour que le client puisse souscrire à un contrat plus avantageux. Mon rôle était de vérifier que les règles de gestion étaient correctement appliquées et que les résultats affichés étaient cohérents. »

Florian
« De mon côté, j’ai travaillé sur la partie amont de cette fonctionnalité, à savoir la saisie du contrat dans l’application. Même si le sujet est lié, nous n’avons pas testé les mêmes éléments ni de la même manière. Je me suis concentré sur la fiabilité des calculs et la cohérence des résultats selon les données saisies.

Aujourd’hui, on teste tous les deux des objets connectés, chaque device dispose de ses propres spécifications et fonctionne différemment. Il est donc indispensable d’être formé à son usage pour comprendre son comportement avant de le tester. »

Travaillez-vous en binôme ? Dans la même équipe ?

Nous ne travaillons pas en binôme au quotidien et nous ne sommes pas forcément dans la même équipe. En règle générale, chaque QA est responsable d’un sujet à la fois.

L’équipe est composée de 4 QA, voire 5 en incluant le test lead.

Valentin
« Le test lead joue un rôle central, c’est lui qui  trie les sujets et les répartit entre les testeurs en fonction des affinités, des sujets déjà traités et de la bande passante de chacun. Cela permet de constituer une équipe de test complète et équilibrée. »

Vous testez principalement des objets connectés, comment ça s’organise ?

Pour tester un objet connecté, il est indispensable de l’avoir physiquement avec soi. Les développeurs en ont besoin, mais les testeurs également.

L’organisation se déroule généralement de la façon suivante : :

  • attribution du sujet,
  • kick-off pour découvrir l’objet et son fonctionnement,
  • analyse des User Stories,
  • déploiement d’une version applicative sur l’environnement de test,
  • tests fonctionnels sur l’application et sur l’objet.

Les développeurs (back-end, iOS et Android) mettent à disposition une version dédiée sur un environnement de test afin que les tests puissent être réalisés avant le passage en préproduction puis en production.

Les tests s’effectuent en trois grandes phases, sur une durée d’environ trois semaines :

  • tests sur environnement de test,
  • passage en préproduction,
  • phase de non-régression avec plusieurs objets connectés.

Cette dernière phase permet de vérifier que tous les objets s’imbriquent correctement : installation dans l’application, pilotage, changement de mode et remontée fiable des informations. En production, tout est censé fonctionner immédiatement.

Nous testons aussi bien des objets en prototype, qui ne sont pas encore commercialisés, que des objets déjà présents sur le marché et intégrés au catalogue. Parfois, il arrive même que l’on teste des objets qui ne seront pas commercialisés.

Valentin
« J’ai piloté quatre modules permettant de connecter des objets qui ne l’étaient pas initialement, comme des volets électriques. Deux modules ont été mis en production, tandis que les deux autres présentaient des problèmes de déconnexion et d’instabilité, ce qui a conduit à repousser leur sortie. »

Vous avez dû être formés sur ces objets pour les comprendre ?

Oui, nous avons dû suivre une formation avec habilitation électrique. Elle est indispensable pour manipuler les objets en toute sécurité et comprendre les contraintes liées à l’électricité lors des phases de test.

Qu’est-ce que ça change concrètement dans la façon de tester ?

Florian
« Le test d’objets connectés est par nature très instable. Il arrive fréquemment qu’un objet ne parvienne pas à se connecter, notamment à cause du réseau ou de la multiplicité des connexions simultanées.

Au début, ça fait bizarre, surtout lorsqu’une journée entière est consacrée à tenter de connecter un objet.

Les objets peuvent aussi être défectueux. Il est donc recommandé d’en tester plusieurs exemplaires pour déterminer si le problème provient de l’objet lui-même ou de l’application. »

Valentin
« Certains tests que l’on estime rapides peuvent finalement prendre une journée complète. De nombreux paramètres dépendent de l’objet, ce qui rallonge considérablement les phases de test.

Les tests ne se font pas uniquement derrière un écran. Ils sont plus physiques et plus stimulants, et nécessitent de comprendre comment l’objet communique avec le réseau, la box et l’application. »

Est-ce que vous avez une approche différente des tests dans votre façon de travailler avec le métier ?

Oui, clairement. Lorsqu’un dysfonctionnement apparaît, il peut provenir de la box, de l’objet, du back-end ou du front-end.

Les échanges avec les développeurs sont donc plus directs et souvent en face-à-face pour comprendre rapidement l’origine du problème et faire une démonstration en live.

Le travail est moins protocolaire que sur des projets purement applicatifs. Il nécessite également plus d’anticipation, notamment pour organiser les jours de télétravail et savoir quand tester les objets.

Il est parfois possible d’emporter les objets chez soi, sauf lorsqu’ils sont trop volumineux ou trop dangereux pour une installation domestique, notamment pour les radiateurs, les climatiseurs, etc…

Aujourd’hui, il n’y a pas du tout d’automatisation des tests. La manipulation physique des objets rend l’automatisation très complexe. Les tests sont donc exclusivement manuels et reposent sur l’intervention humaine. Certains tests pourraient être automatisés mais pas pour tous les objets.

Qu’est-ce qui vous plaît dans cette originalité ?

Florian
« Ce qui me plaît énormément, c’est le côté “unique”. Après plusieurs années dans le bancaire à tester toujours la même application, travailler sur des objets connectés apporte beaucoup de diversité. On change régulièrement de sujet et on a une certaine liberté dans le choix des missions. Il n’y a aucune routine. »

Valentin
« Les cycles sont très dynamiques, avec des itérations d’environ un mois. À peine un sujet terminé, un autre commence et apporte de la nouveauté. Selon les objets, les User Stories sont très différentes et l’on apprend tous les jours, aussi bien sur le plan fonctionnel que technique. »

Vous avez des conseils pour les testeurs qui commencent à tester des objets connectés ?

Florian
« Lorsqu’un objet ne se connecte pas, il est important d’en tester un second pour vérifier que le problème ne vient pas du matériel. Mon meilleur conseil, c’est de dire qu’il ne faut surtout pas se précipiter et prendre le temps de comprendre les mécanismes de l’objet. »

Valentin
« Chaque objet utilise un protocole différent et certains sont plus capricieux que d’autres. Il est très important de suivre scrupuleusement les instructions de l’application et de bien lire la documentation, notamment pour éviter tout risque lié à l’électricité. On voudrait parfois passer au-dessus des règles mais il ne faut surtout pas se mettre en danger.

Tester des objets connectés demande beaucoup de curiosité, de débrouillardise et une réelle capacité d’adaptation. »


8 avril 2026

Envie d'une autre lecture ?

Photo d'Olivier Denoo lors du tournage de l'épisode de podcast QG Qualité
27 mai 2026

On parle ISTQB & CFTL dans l’épisode 9 de QG Qualité avec Olivier Denoo

Dans cet épisode de QG Qualité, nous recevons Matthieu Leroux-Huet, freelance spécialisé en tests de performance depuis plus de 15 ans.

À travers son parcours, ses premières expériences et son lancement en indépendant, il partage une vision concrète d’un domaine encore entouré de nombreuses incompréhensions.

Lire l'article
Affiche Apéro QA le jeudi 18 juin à 18h30 avec présentation des conférences.
13 mai 2026

Invitation – Apéro QA le jeudi 18 juin au Barrel !

Le jeudi 18 juin, SSID réunit la communauté QA pour un Apéro QA, une soirée d’échanges, de retours d’expérience et de discussions autour d’un verre et la présentation de deux conférences.

Inscriptions en ligne !

Lire l'article
Photo de Rémy notre Testeur technico-fonctionnel
6 mai 2026

Regards croisés sur la double casquette Test Analyst & Business Analyst de Rémy !

Rémy Dupilet, testeur chez SSID depuis 5 ans, nous partage son retour d’expérience sur une mission singulière chez son client : un rôle hybride mêlant l’exigence de la Qualité Logicielle (QA) et la vision stratégique du Business Analyst (BA).

Lire l'article