Plateforme
QA automatisée pour une livraison logicielle IA sérieuse
Chaque modification écrite par IA est testée comme un utilisateur l'expérimenterait — dans un vrai navigateur, avant la livraison et après l'arrivée en production.
Ciao QA est la couche de test automatisée de la plateforme : replays de navigateur déterministes, tests auto-réparants, smoke gates avant publication et contrôles en production après publication. Contrairement aux suites de tests qui se dégradent quand l'application change, les tests de Ciao se réparent eux-mêmes quand l'UI évolue — si bien que la couverture suit le rythme du développement à vitesse IA au lieu de prendre du retard.
Publié 2026-07-03 · Dernière mise à jour 2026-07-03
L'IA écrit plus vite que les humains ne peuvent tester
Le développement assisté par IA déplace le goulot d'étranglement. Du code qui prenait autrefois un sprint arrive en un après-midi — et chacune de ces modifications peut casser le checkout, le login ou le rapport qu'un directeur lit chaque lundi. Cliquer manuellement dans l'app ne tient pas à ce rythme, et les suites de tests traditionnelles se dégradent dès que l'UI bouge sous elles.
Ciao QA est conçu pour ce rythme. Il exécute des replays de navigateur déterministes, des tests auto-réparants, des smoke gates avant publication et des contrôles en production après publication — automatiquement, sur chaque modification, dans le cadre du même cycle qui a écrit le code.
Comment fonctionne QA
QA s'exécute dans le cadre du cycle de livraison — rien ici n'est un outil séparé à adopter ou un pipeline à maintenir.
1. Les flux sont capturés comme des replays
Les parcours utilisateurs clés — se connecter, créer un enregistrement, passer à la caisse — sont capturés comme des replays de navigateur déterministes : mêmes étapes, mêmes entrées, mêmes résultats attendus, à chaque exécution.
2. Les tests s'exécutent dans un vrai navigateur
Les replays s'exécutent contre l'application réelle comme un utilisateur l'expérimenterait — vrai rendu, vrai réseau, vraie auth — pas contre des composants simulés.
3. Les tests se réparent au lieu de se dégrader
Quand l'UI change légitimement — un bouton se déplace, un libellé est reformulé — les tests auto-réparants se mettent à jour pour correspondre à la nouvelle réalité au lieu d'échouer sur un sélecteur périmé et d'être supprimés.
4. Les smoke gates tiennent la porte
Avant toute publication, les smoke gates exécutent les replays critiques. Une porte en échec arrête la publication, si bien que la version cassée ne passe pas.
5. Les contrôles en production ferment la boucle
Après publication, des contrôles s'exécutent contre l'application en direct pour confirmer que la release se comporte bien en production, où la configuration et les données sont réelles.
6. Les échecs reviennent comme du travail
Un contrôle en échec revient dans le cycle avec du contexte — quelle étape a échoué et ce qui était attendu — là où le correctif peut être construit et re-vérifié.
Pourquoi c'est important
Le déterminisme est important parce que les tests instables entraînent les équipes à ignorer le rouge. Quand un replay échoue, quelque chose a réellement changé — ce qui rend le signal digne d'action et la porte digne de confiance.
L'auto-réparation est importante parce que l'alternative est une suite qui meurt silencieusement. Une couverture qui s'entretient elle-même suit le rythme du changement à vitesse IA, si bien que la centième modification est testée aussi soigneusement que la première. Et des portes des deux côtés de la publication signifient que « ça marchait en aperçu » et « ça marche en production » sont tous deux vérifiés, pas supposés.
L'habitude que cela construit est le point clé. Quand chaque publication est contrôlée et chaque release vérifiée en production, livrer cesse d'être un acte de courage. Les équipes font plus de modifications, en morceaux plus petits, parce que le coût d'avoir tort est une publication arrêtée plutôt qu'un lundi cassé — et l'audit trail montre chaque porte que chaque release a franchie.
Qui l'utilise
QA est l'un des six rôles de l'organisation logicielle IA de Ciao, et différentes personnes s'y appuient différemment.
- Non-ingénieurs qui livrent de vraies apps — Les personnes dont on ne peut pas attendre qu'elles écrivent des suites de tests en obtiennent une quand même — capturée à partir des flux que leur app a réellement.
- Responsables d'ingénierie — Des portes plutôt que des promesses : une publication qui a échoué à son smoke gate ne sort pas, quel que soit celui qui l'a demandée.
- Agences — Chaque application cliente obtient des parcours protégés sans budget QA par projet ni suite maintenue à la main par client.
- Équipes d'opérations et de support — Les contrôles en production détectent les régressions dans l'app en direct, si bien que les problèmes apparaissent comme des constatations plutôt que des tickets de support.
Notes sur la sécurité et la gouvernance
- ✓ Les smoke gates s'exécutent avant chaque publication ; les contrôles en production après.
- ✓ Les replays sont déterministes — mêmes étapes, mêmes données, même résultat attendu à chaque exécution.
- ✓ L'auto-réparation garde la couverture vivante à mesure que l'UI évolue.
- ✓ Les résultats de QA alimentent la santé du projet dans Conductor, visible sur toute la fleet.
- ✓ Les résultats de test rejoignent l'audit trail append-only aux côtés des merges et déploiements.
Une suite maintenue à la main vs Ciao QA
Le contraste avec une suite maintenue à la main est structurel, pas cosmétique.
| Suite de tests maintenue à la main | Ciao QA | |
|---|---|---|
| Rédaction | Les ingénieurs écrivent et mettent à jour les scripts | Les flux sont capturés comme des replays pendant la construction de l'app |
| Changements d'UI | Les sélecteurs cassent ; les tests sont ignorés | Les tests s'auto-réparent pour correspondre à la nouvelle UI |
| Avant la release | La CI s'exécute si quelqu'un l'a configurée | Les smoke gates arrêtent une publication en échec |
| Après la release | Monitoring, si configuré | Les contrôles en production vérifient l'app en direct |
| Échecs instables | Réexécuter et espérer | Replays déterministes — rouge signifie que quelque chose a changé |
Questions fréquentes
Que signifie déterministe ici ?
Les replays exécutent les mêmes étapes avec les mêmes entrées et les mêmes attentes à chaque fois. Un échec signifie donc que l'application a changé, pas que le test a vacillé — c'est ce qui rend raisonnable de bloquer une publication dessus.
Dois-je écrire les tests moi-même ?
Non. Les parcours clés sont capturés pendant la construction de l'application, et vous pouvez ajouter les flux les plus importants pour votre activité. Les ingénieurs peuvent inspecter et étendre ce qui s'exécute — cela fait partie du projet, pas une boîte noire.
Que se passe-t-il quand un smoke gate échoue ?
La publication s'arrête. L'échec revient avec du contexte — l'étape, l'attente, ce qui s'est passé à la place — si bien que le correctif peut être fait et re-vérifié. Quand la porte est verte, la publication continue.
Que sont les contrôles en production, et pourquoi les exécuter après publication ?
L'aperçu et la production diffèrent : la configuration, les données, les intégrations et le trafic ne sont réels que dans l'un des deux. Les contrôles en production s'exécutent contre l'application en direct après chaque release pour confirmer qu'elle se comporte là où ça compte, et les constatations remontent vers Doctor et SysOps pour diagnostic et réponse.
Cela remplace-t-il les ingénieurs QA ?
Non — cela change ce sur quoi ils passent leur temps. Le travail mécanique de garder les tests navigateur vivants est automatisé ; les humains décident quels parcours sont critiques, revoient ce que les portes attrapent et relèvent la barre au fil du temps.
Pages associées
Voyez tout le cycle de livraison en une seule démo.
QA automatisée pour les applications construites par IA | Ciao