QA u002F SDET

Rattaché.e directement au CTO et au VP Engineering, le/la candidat.e rejoindra une équipe technique composée de développeurs seniors, d’un DevOps et d’un pôle Produit (CPO + PO).

La GTB (Gestion Technique du Bâtiment) est un secteur historiquement marqué par des problèmes de fiabilité qui ont freiné son adoption à grande échelle.

SCorp-io a fait de la qualité et de la robustesse un axe de différenciation fondamental : c’est ce qui a permis de convaincre (plus de 250 bâtiments équipés), et c’est ce qui permettra d’en convaincre davantage et de les fidéliser durablement dans un marché où la confiance se construit sur la durée.

Dans ce contexte, SCorp-io crée un poste d’Ingénieur QA / SDET — le premier de la structure — avec une mission structurante : définir et déployer une stratégie de tests cohérente sur l’ensemble de la plateforme, en complément d’une couverture unitaire déjà solide (60% de couverture sur plus de 100 000 lignes de code) et d’un monitoring en place (Prometheus, Loki, Grafana).

Les missions :

Stratégie & environnement qualité

• Auditer l’existant et définir les priorités : tests d’intégration, end-to-end, tests de charge, tests de contrat entre services,

• Mettre en place un environnement de QA dédié, en collaboration avec le DevOps,

• Définir des indicateurs de fiabilité mesurables (SLI/SLO) et contribuer à l’amélioration du monitoring et de l’alerting Grafana.

  Automatisation & outillage

• Implémenter des tests end-to-end sur les parcours critiques (frontends Angular, API REST, flux WebSocket temps réel),

• Reprendre et industrialiser les tests de charge initiés sur les flux MQTT (mqHammer) et les étendre à l’ensemble des composants critiques de la plateforme,

• Développer des outils internes (code, automatisation no-code, vibe-coding)  lorsque les solutions existantes ne couvrent pas le besoin : simulateurs de données terrain, générateurs de charge, outils de replay de messages,

• Intégrer l’ensemble des tests dans les pipelines CI/CD (Bitbucket Pipelines),

• Contribuer à la sécurisation des endpoints API exposés aux partenaires.

  Communication & transparence opérationnelle

• Mettre en place une page de statut publique permettant de communiquer en temps réel l’état de la plateforme, les incidents en cours et les maintenances planifiées,

• Définir et automatiser les processus de communication en cas d’incident ou de mise à jour critique,

• Connecter les indicateurs de fiabilité (SLO) à la page de statut pour une détection et une communication proactives.

  Culture qualité & collaboration

• Travailler en lien étroit avec le pôle Produit pour automatiser progressivement les validations fonctionnelles aujourd’hui réalisées manuellement,

• Collaborer avec l’équipe support pour transformer les incidents terrain en cas de tests reproductibles et pérennes,

• Accompagner les développeurs sur la testabilité du code et les bonnes pratiques associées.

L’environnement technique

La plateforme SCorp-io repose sur une architecture microservices event-driven, traitant en temps réel des données issues d’automates industriels via des protocoles terrain (OPC-UA, BACnet, Modbus, Modbus RTU, MQTT). Ces données transitent par un pipeline Kafka, sont transformées par des topologies Kafka Streams puis restituées aux utilisateurs via des interfaces Angular en WebSocket et historisées dans une base de données time-series.

Stack technique :

• Frontend : Angular 19, TypeScript, Tailwind CSS

• Backend : Java 21, Spring Boot 4, Micronaut 4, Kafka Streams

• Messaging : Apache Kafka, EMQX, Confluent Schema Registry (Avro)

• Bases de données : PostgreSQL, ClickHouse, Warp10, Redis

• Feature flags : LaunchDarkly

• Cloud & Infrastructure : Scaleway, Kubernetes

• CI/CD & Qualité : Bitbucket Pipelines, SonarCloud, JaCoCo

• Monitoring : Prometheus, Loki, Grafana

État actuel des tests :

• 60% de couverture de tests sur plus de 100 000 lignes de code

• Couverture unitaire solide sur les microservices Java (JUnit 5, Mockito, Kafka Streams test utils)

• Topologie Kafka Streams du service de transformation intégralement couverte par des tests d’intégration

• Tests d’intégration partiels sur les autres services

• Tests de charge MQTT initiés (mqHammer), à reprendre et industrialiser

• Pas d’environnement QA dédié à ce jour