Agents qualité et sécurité

Les agents qualité et sécurité sont notre propre outil. Il contrôle chaque build sur un parcours fixe : QA, UX, sécurité, pentest, SEO/AEO, audit technique avec Lighthouse, revue de code. Chaque constat confirmé est corrigé avec un test qui échoue avant la correction et réussit après, et chaque bug reste un test permanent.

Notre propre produit

Secteur	Outils et plateformes internes
Défi	Responsabilité
Contexte de décision	Évaluation de produit
Complexité	Élevée
Service	Plateforme

Si vous vous demandez pourquoi un site web ou une plateforme d'iwebforyou n'est jamais livré « tel qu'il est sorti », la réponse est ici : chaque projet passe par le même contrôle avant d'arriver chez vous. Le tableau montre ce que chaque agent examine et quand il passe, et le texte explique ce que cela signifie pour le client.

Agent	Ce qu'il examine	Passage
SEO/AEO	Si les pages peuvent être trouvées et citées par les moteurs de recherche et de réponses (sites web)	Une fois
Audit technique	La qualité des pages, mesurée avec Lighthouse (sites web)	Une fois
Revue de code	Le code du framework utilisé, pour vérifier qu'il est correct	Jusqu'à 2 tours
UX	La façon dont les pages fonctionnent pour une personne	Une fois
Sécurité	Les points faibles de l'application	Jusqu'à 3 tours
Pentest	Une attaque simulée, pour voir ce que ferait un vrai attaquant (plateformes ou sites avec boutique en ligne ou réservations)	Jusqu'à 2 tours
QA	L'application entière, comme l'utiliserait un client	Jusqu'à 2 tours

Agents qualité et sécurité Quelle était la situation de départ ?

Nos builds sont produits par le Planner, et chaque fonction passe déjà ses propres tests avant d'être acceptée. Mais les fonctions doivent aussi marcher correctement toutes ensemble. Une page qui marche seule peut être touchée quand on en ajoute une autre. Un formulaire sûr en lui-même peut être accessible par un autre chemin.

C'est pourquoi, une fois le build approuvé, une deuxième étape suit, volontairement séparée de la première. Les agents n'ont pas écrit le code. Leur travail est de l'examiner d'un œil critique.

Cette étape donne son sens au mot « contrôlé » dans notre travail. Les clients la voient rarement, c'est pourquoi nous la décrivons ici en détail.

Agents qualité et sécurité Quel était le problème ?

Chaque contrôle voit ce qu'il a été conçu pour chercher. Une analyse de sécurité repère des points faibles, pas un formulaire confus. Un contrôle visuel juge l'apparence, pas un endpoint sans protection. Un testeur qui connaît bien l'application ne trébuche pas là où trébucherait un nouveau visiteur. Pour avoir une vue complète, il faut plusieurs contrôles différents.

Le deuxième sujet est ce qui se passe après un constat. Un problème est vraiment réglé quand on note aussi comment il a été repéré. Un constat accompagné d'un test reste réglé, car le test le surveille ensuite.

Agents qualité et sécurité Quelles contraintes l'ont façonné ?

Trois contraintes. Le parcours doit avoir une fin claire : chaque agent termine ses tours et s'arrête. Chaque constat est consigné et reçoit une décision avant que le build continue : il est soit corrigé, soit accepté en connaissance de cause, avec une raison écrite. Le travail ne laisse pas de données de test dans le contenu réel.

Le CMS est un cas particulier. Dans un site, il est en lecture seule. Un constat sur le CMS lui-même est noté comme tel et corrigé dans son propre dépôt, pour que la correction arrive sur tous les sites et pas sur un seul.

Les limites sont écrites dans le code : 5 sessions par tâche, 3 réparations de la porte qualité, 3 essais par tour. Si un sujet atteint une limite, il passe au responsable du projet pour décision, et l'exécution continue.

Agents qualité et sécurité À quoi faisons-nous attention dans le contrôle ?

Le premier point est la suite donnée au rapport. Un long rapport n'a de valeur que si chaque constat reçoit une décision. C'est pourquoi aucun constat ne reste en attente avec l'étiquette « à vérifier ». Les notes sur ce qu'un agent n'a pas couvert sont lues aussi, car elles peuvent être la ligne la plus importante du rapport.

Le deuxième point est celui des boucles. Quand un agent change le code et qu'un autre repart à cause de ce changement, le parcours a besoin d'une fin claire. Les tours fixes l'assurent.
Le troisième point est la vérification. Quand un outil d'analyse signale un « problème possible », la première étape est de vérifier que le problème est réel. Ce n'est qu'ensuite qu'on décide de corriger ou de rejeter.

Agents qualité et sécurité Quelle est l'approche ?

Le parcours est le même dans chaque projet. Chaque agent passe une fois, dans un ordre fixe, avec un nombre de tours défini. Le deuxième tour n'a lieu que si le premier a corrigé quelque chose. La liste numérotée donne l'ordre, et le tableau plus haut montre ce que chacun examine.

SEO/AEO et audit technique (Lighthouse), pour les sites web.
Revue de code, avec un deuxième tour seulement pour les corrections du premier.
UX. Les constats d'esthétique deviennent des propositions dans un fichier à part et attendent l'accord du responsable, au lieu d'être appliqués automatiquement.
Sécurité en trois tours au plus (une liste de contrôles, puis une recherche ouverte, puis une liste mise à jour). Pentest en deux tours au plus, pour les plateformes ou les sites avec boutique en ligne ou réservations.
QA en deux tours sur toute l'application. Un simple site d'information reçoit une QA légère. Un site avec boutique en ligne ou réservations reçoit une QA intensive, qui essaie volontairement de le « casser ».
Le backlog devient des propositions (documentation et refactoring, uniquement sous forme de propositions).
Dernier contrôle de sécurité, et pentest si nécessaire, une seule fois, sur les changements de l'étape 4. Il corrige ce qu'il trouve, puis s'arrête, même pour des constats Critical ou High.
Une exécution complète de la porte qualité, avec les tests e2e. Aux étapes intermédiaires, seule la porte rapide tourne.
Rapports.

Lighthouse, utilisé dans l'audit technique, est un outil automatique open source. Il mesure la qualité d'une page en performance, accessibilité, SEO et bonnes pratiques (voir les Sources).

Agents qualité et sécurité Quelles ont été les décisions principales ?

Il y a six décisions principales. Chaque constat confirmé est corrigé avec un test, chaque bug devient un test permanent et chaque constat reçoit une décision. Les notes de couverture sont lues, la liste de sécurité grandit et un registre garde l'état. Chacune est expliquée ci-dessous.

Chaque constat confirmé est corrigé, même les petits

Chaque constat compte, quelle que soit sa gravité. Chaque correction s'accompagne d'un test qui échoue avant et réussit après, pour que la correction soit prouvée et qu'elle dure.

Chaque bug devient un test permanent

Un bug trouvé par la QA reste dans un dossier de tests de non-régression. Ce qui a été trouvé une fois est ensuite vérifié à chaque build.

Chaque constat reçoit une décision

L'outil vérifie chaque affirmation et tranche : il la corrige ou il la rejette avec une raison écrite. Chaque constat est prouvé ou réfuté par des éléments concrets.

Toutes les notes sont lues

Les notes de couverture des agents sont lues, car la note sur ce qu'un agent n'a pas couvert peut être la ligne la plus importante de son rapport.

La liste grandit avec les constats

La liste de contrôle de l'agent de sécurité s'élargit chaque fois qu'on trouve un nouveau type de faiblesse. Ainsi, le projet suivant démarre avec ce qu'a appris le précédent.

Une seule source de vérité

Un registre note l'état de chaque constat : corrigé avec un commit, rejeté, accepté, transmis au responsable, ouvert ou non vérifié.

Agents qualité et sécurité Quel résultat attendre ?

Le résultat est un build avec une trace que l'on peut suivre : ce que chaque agent a examiné, ce qu'il a trouvé, ce qui a changé et quel test protège désormais ce point. Pour le client, cela veut dire moins d'inconnues le jour de la livraison. Cela veut aussi dire un dossier qui soutient la fiabilité du site et sa présence dans la durée.

Aucun contrôle ne peut promettre un build sans le moindre défaut, et nous ne le prétendons pas. Nous ne publions pas de nombres de constats, car ils seraient choisis et non neutres. Ce que la méthode garantit est clair : le parcours est fixe, les constats sont prouvés avant d'être corrigés et les tests restent.

Pour voir où cette étape se place dans un projet, lisez notre processus. Pour le côté sécurité sur une vraie plateforme, voyez l'infrastructure AWS d'une plateforme de santé, ou démarrez un projet.

Agents qualité et sécurité Sources

Chrome for Developers, Introduction to Lighthouse

Agents qualité et sécurité Questions fréquentes

Les agents remplacent-ils le contrôle par un humain ?

Non. Les agents font le contrôle long et répétitif. Un humain décide de ce qui demande un jugement humain : les choix de conception, le contenu et les priorités. Les constats des agents sont vérifiés, puis corrigés ou rejetés avec une raison.

Que veut dire « un test qui échoue avant » ?

Pour chaque vrai problème, nous écrivons un contrôle automatique qui échoue tant que le problème existe. Ensuite, nous corrigeons le problème, et le contrôle réussit. Si le problème revient, le contrôle repasse au rouge et nous le voyons tout de suite.

Le pentest est-il différent d'une analyse de sécurité ?

Oui. L'analyse cherche des points faibles connus, à partir d'une liste. Le pentest est une attaque simulée : il essaie de combiner de petites faiblesses, comme le ferait un vrai attaquant. Nous utilisons les deux sur les plateformes, ainsi que sur les sites avec boutique en ligne ou réservations.

Chaque site web passe-t-il par tous les contrôles ?

Le parcours s'adapte au projet. Les contrôles SEO/AEO et Lighthouse concernent les sites web. Le pentest concerne les plateformes ou les sites avec boutique en ligne ou réservations, et un site d'information reçoit une QA plus légère. Voyez ce que comprend un site type sur la page des sites web d'entreprise.

Étape suivante: Agents qualité et sécurité

Lancez votre projet

Envoyez une demande de projet ou vérifiez gratuitement votre site actuel. Nous lisons chaque message nous-mêmes.

Démarrer un projet Vérifier votre site