Ingénieur QA

Présentation du poste

Regara est une plateforme d’intelligence clinique et réglementaire pour l’industrie des sciences de la vie. Les entreprises de dispositifs médicaux, pharmaceutiques et biotechnologiques nous utilisent pour planifier et préparer tout ce dont elles ont besoin pour mettre un produit sur le marché — stratégie réglementaire, protocoles cliniques, rapports d’études et dossiers de soumission — sur plusieurs marchés.

L’IA est le produit. Nous exploitons une plateforme d’agents autonomes qui recherchent des données en temps réel, raisonnent dessus et rédigent de bout en bout des documents techniques complets. Cela fait de la qualité un problème réellement difficile. Les résultats sont générés plutôt que figés, une même entrée peut produire deux textes différents, et le livrable final est un document qu’un client dépose auprès d’une autorité réglementaire.

Ce qui distingue ce poste de la plupart des postes QA. Ici, un défaut n’est pas un bouton mal aligné. C’est un chiffre erroné, une affirmation non étayée ou une citation dont la source ne dit pas ce pour quoi elle est citée. Un document généré peut être fluide, bien mis en forme et faux — et rien à l’écran ne vous le signalera. Les détecter avant le client, c’est le métier.

Il s’agit d’un poste entièrement dédié à la qualité. Vous n’êtes pas recruté pour développer des fonctionnalités entre deux cycles de test ; vous l’êtes parce que le problème de qualité le plus difficile de l’entreprise exige quelqu’un qui y consacre toute son attention. Vous serez responsable d’un périmètre de test de bout en bout — des sessions exploratoires et des cas que vous rédigez, au suivi des défauts, jusqu’à la confirmation du correctif en production.

Ce sur quoi vous travaillerez concrètement

01 · Tests exploratoires et fonctionnels

Utilisez le produit comme le ferait un client, puis cherchez les endroits où il cède.

• Mener des passes fonctionnelles et UI/UX sur les flux de lancement, les vues de résultats et les outils d’administration.
• Sonder les limites — états vides, entrées surdimensionnées, exécutions interrompues, permissions, et différences entre navigateurs et tailles d’écran.
• Tester les parcours que les clients utilisent réellement, et pas seulement des écrans isolés.
• Retester chaque version et repérer les régressions.

02 · Conception des tests et couverture de non-régression

Transformez ce que vous apprenez en quelque chose de reproductible qui survit à chaque version.

• Rédiger et maintenir des cas de test et des check-lists couvrant les parcours utilisateurs essentiels.
• Être responsable de la suite de non-régression que l’équipe exécute avant chaque version, et la tenir à jour à mesure que le produit évolue.
• Cartographier la couverture par rapport au périmètre du produit et dire clairement où sont les lacunes.
• Prioriser selon le risque, pas selon la facilité à tester. Une suite exhaustive sur ce qui est peu critique et rien sur ce qui l’est est pire que pas de suite du tout, car elle donne l’illusion d’une couverture.

03 · Vérification des résultats générés

La moitié la plus passionnante de ce poste, et celle pour laquelle il n’existe pas de méthode établie.

• Contrôler la cohérence interne des livrables générés — chiffres, renvois, complétude des sections et mise en forme.
• Rapprocher les identifiants et références produits par un agent de la source de référence.
• Signaler les affirmations non étayées, les attributions erronées et les citations dont le contenu ne soutient pas l’affirmation qui les cite. L’intégrité des citations est l’attribut qualité le plus critique de ce produit.
• Évaluer les résultats par rapport à des exemples de référence et réinjecter les conclusions dans la suite d’évaluation.
• Concevoir des approches de test adaptées à des résultats non déterministes — là où « a-t-il produit la chaîne attendue ? » est la mauvaise question.

04 · Signalement et tri des défauts

Un rapport de bug est un livrable. Rédigez-le pour que l’on puisse agir sans avoir à vous poser de question.

• Isoler une reproduction minimale et fiable — pas « ça plante parfois ».
• Signaler avec les étapes de reproduction, le résultat attendu et le résultat obtenu, l’environnement et une gravité que vous pouvez justifier.
• Rattacher un défaut à l’exigence ou au parcours qu’il compromet.
• Distinguer un bug de code d’un problème de qualité du modèle. Ils relèvent de personnes différentes et se corrigent différemment ; mal les orienter fait perdre une semaine à tout le monde.
• Suivre chacun jusqu’à la vérification du correctif.

05 · Validation des versions et signal qualité

Quelqu’un doit pouvoir dire si une version est sûre — et avoir raison.

• Mener la validation des versions et donner un avis clair et étayé sur l’état de préparation d’un build.
• Suivre le signal qualité dans le temps — tendances des défauts, taux d’échappement et zones du produit où les problèmes reviennent.
• Rendre compte par écrit de l’état de la qualité à l’équipe d’ingénierie, y compris ce que personne n’a envie d’entendre.
• Donner l’alerte tôt lorsqu’une version prend une mauvaise tournure. Un avertissement tardif ne vaut guère mieux qu’aucun.

06 · Automatisation des tests

Transformez les vérifications manuelles en vérifications automatiques — là où le gain est réel.

• Étendre la couverture backend avec pytest et la couverture frontend avec Vitest et React Testing Library.
• Écrire des tests end-to-end au niveau du navigateur pour les parcours les plus fréquentés.
• Maintenir les suites branchées sur GitHub Actions pour que les échecs apparaissent dans la pull request plutôt qu’après le merge.
• Automatiser avec discernement. Une suite fragile à laquelle personne ne fait confiance coûte plus cher que la passe manuelle qu’elle a remplacée.

Notre stack

• Backend — Python 3.12, FastAPI, SQLAlchemy 2.0, Pydantic v2, Postgres / SQLite, pytest
• Frontend — React 19, TypeScript (strict), Vite, TanStack Router + Query, Tailwind, shadcn/ui, Vitest + RTL
• IA — API de LLM de pointe (Claude), serveurs d’outils MCP, RAG, harnais d’évaluation et évaluateurs à résultats de référence
• Infrastructure — AWS (ECS/EC2, ECR, SQS, S3), Docker, GitHub Actions

Vous n’êtes pas censé tout connaître. L’essentiel de vos tests porte sur l’application plutôt que sur le code — mais c’est ce que vous lirez pour remonter un bug à sa source, et ce que vous écrirez pour étendre les suites automatisées.

Profil recherché

Requis

• Environ 2 à 5 ans dans un poste de QA, de qualité logicielle ou d’ingénierie de test, sur un vrai produit avec de vrais utilisateurs.
• Diplôme en informatique, génie informatique ou domaine connexe — ou expérience pratique équivalente.
• À l’aise pour lire et écrire du code dans au moins un langage. Python ou TypeScript vous rapprochent le plus de notre stack, mais Java, C++ ou tout autre langage conviennent.
• Un sens du détail qui repère la valeur subtilement fausse, pas seulement la page qui ne se charge pas.
• Une rédaction technique claire. Nous lirons vos rapports de bugs plus souvent que votre code.
• Capacité à lire une source primaire — une spécification, une norme, un contrat d’API — et à vérifier une implémentation exactement par rapport à ce qu’elle dit.
• Méthodique face à l’ambiguïté. Vous ramenez une plainte vague à une reproduction minimale au lieu de la remonter telle quelle.
• Expérience pratique d’au moins un framework de test — pytest, Vitest, Playwright, Selenium ou équivalent.
• À l’aise avec Git et les workflows de pull request.
• Prêt à bloquer une version. Ce poste doit parfois dire qu’un build n’est pas prêt alors que d’autres l’attendent. Le dire, c’est le métier.
• Disponible pour travailler sur site à Las Vegas à temps plein, et autorisé à travailler aux États-Unis.

Souhaité

• Expérience du test de résultats générés par IA ou LLM, ou de la conception et de l’exécution de harnais d’évaluation.
• Expérience dans des secteurs réglementés — dispositifs médicaux, pharmaceutique, recherche clinique — ou de 21 CFR Part 11, des BPx (GxP) ou de la validation de systèmes informatisés.
• Tests d’API et maîtrise de SQL suffisante pour vérifier les données directement et pas seulement via l’interface.
• Expérience CI/CD, en particulier avec GitHub Actions.
• Tests d’accessibilité, ou tests de performance et de charge.
• Expérience de la mise en place d’un processus de test là où il n’en existait pas.
• Expérience en startup, y compris l’aisance à travailler avant que le processus n’existe.

Notre façon de travailler

• Rien n’est livré sur la foi d’un seul bel exemple. Chaque modification de prompt, de recherche documentaire ou d’outil est évaluée par rapport à une suite de non-régression et à un ensemble de résultats notés avant d’atteindre un client. Nous itérons sur des chiffres.
• Boucle rapide jusqu’à la production. Vous testerez sur l’environnement de staging dès votre première semaine, et les bugs que vous signalez sont corrigés assez vite pour que vous vérifiiez vous-même le correctif.
• Vous êtes responsable d’un périmètre de test de bout en bout. Des sessions exploratoires et des cas que vous rédigez, à l’automatisation et au suivi des défauts, jusqu’à la confirmation du correctif en production. Personne ne vous tend un script à exécuter en gardant la réflexion pour soi.
• Petite équipe, collaboration directe. Vous travaillez aux côtés de l’équipe d’ingénierie fondatrice, avec une revue de code sur chaque pull request que vous ouvrez.
• Nous construisons à la pointe. Nous suivons les nouvelles versions de modèles, les capacités de contexte et de cache et les outils d’agents dès leur sortie, et nous reconstruisons autour d’eux lorsqu’ils sont meilleurs. Ce que vous apprenez ici est d’actualité.

Ce que nous attendons de vous

• Les défauts sont trouvés en staging, pas par les clients — et le taux d’échappement diminue.
• Les citations inventées, mal attribuées ou non étayées sont détectées en interne avant qu’un client ne les voie.
• Une exécution de non-régression au vert veut vraiment dire quelque chose, parce que la suite couvre l’essentiel et n’est pas instable.
• Les rapports de bugs sont traités sans question supplémentaire.
• Les lacunes de couverture sont connues et annoncées à l’avance, plutôt que découvertes à la suite d’un incident.
• Les problèmes de qualité du modèle et les défauts de code parviennent aux bonnes personnes du premier coup.
• Les décisions de mise en production reposent sur des éléments probants, et l’ingénierie fait confiance à votre avis.

Pourquoi ce poste existe

La QA traditionnelle suppose une réponse correcte à laquelle se comparer. Ici, le système écrit quelque chose de nouveau à chaque fois, et le mode de défaillance est un document qui se lit parfaitement mais contient une affirmation que sa propre citation ne soutient pas. Ce n’est pas un problème que l’on résout en ajoutant des assertions — il faut quelqu’un qui lise les résultats comme le ferait un régulateur. C’est ce poste.