Chez Ping Europe, messagerie souveraine chiffrée de bout en bout, on veut le beurre et l'argent du beurre : une rapidité d'exécution maximum ET le contrôle total de ce que fait l'application. On vous raconte ici comment on fait.

Pourquoi la vitesse ne suffit pas ?

Même sans avoir expérimenté soi-même le fameux vibe-coding (c'est-à-dire coder une application en se contentant d'envoyer des prompts à une IA), on imagine facilement ce que ça donne. En moins de temps qu'il n'en faut pour écrire cette phrase, l'IA a le temps de développer une fonctionnalité, incluant son interface graphique, ses algorithmes exécutés sur le serveur, ainsi que tous les cas d'erreur. C'est vite grisant pour un humain ! Wow, j'ai développé un site de e-commerce hier soir, trop cool. On connaît bien ce sentiment. En moyenne, on produit chaque mois environ 25 000 lignes de code (incluant la documentation technique). C'est autant de caractères qu'un roman comme Le Rouge et le Noir de Stendhal, chaque mois ! C'est effectivement grisant, on va à une vitesse phénoménale, aucune montagne ne semble trop haute pour être gravie, ça a quelque chose de magique...

Oui, mais (pourquoi faut-il toujours qu'il y ait un « mais » ?).

Mais il faut qu'on s'assure que toutes ces lignes de code correspondent bien à ce que l'on attend. Il faut être certain que l'appli fait bien ce qu'on attend d'elle, que l'interface est compréhensible pour les utilisateurs. Il faut s'assurer que l'affichage est correct sur toutes les tailles d'écran, et toutes les marques de téléphone. Et puis, il y a toutes les questions de sécurité. On manipule des données personnelles : comment circulent-elles sur le réseau, comment sont-elles stockées, est-ce qu'elles apparaissent en clair dans les logs du serveur ? Ce ne sont que des exemples, il existe une multitude de questions à se poser avant de pouvoir valider une application.

Vérifier la vérification

Alors comment fait-on ? Facile, on demande à l'IA de le faire, me direz-vous. Et c'est là que le bât blesse. Si on a besoin de vérifier ce que fait l'IA, il va donc falloir vérifier les vérifications de l'IA. Ça se mord la queue... On est donc condamné, nous autres humbles humains, à vérifier nous-même ce que l'IA produit. C'est tout de suite moins grisant : à chaque fois que l'IA code pendant une heure, un humain doit passer la journée à vérifier que l'application se comporte comme il faut.

Dans le monde d'avant, quand les humains codaient, c'était la taille de l'équipe de développement le goulot d'étranglement (en fait c'est plus compliqué que ça, car la productivité d'une équipe de développeurs n'est pas directement proportionnelle à la taille de l'équipe, mais restons schématiques). Quand une entreprise décidait d'accélérer les développements, elle augmentait le budget du projet afin de grossir l'équipe, et on faisait attention de garder un bon équilibre entre le nombre de testeurs et le nombre de développeurs.

Dans le monde d'aujourd'hui, on a besoin de testeurs, et c'est tout. Ce sont eux qui savent si l'IA a bien travaillé ou pas. Ce sont eux qui sont capables d'assumer la mise à jour d'une application sur un store. Les gains de productivité dépendent principalement de l'efficacité des tests.

Si on fait tout à la main, c'est ingérable. Beaucoup trop lent, et surtout l'expérience montre que ça laisse beaucoup de trous dans la raquette. Alors tout le monde s'organise et essaie d'automatiser les tests. Et pour ça, les IA sont très fortes. Elles développent des tests automatiques plus vite que leur ombre ! Oui, mais. On est revenu au point de départ. Comment on va vérifier tout ça ?

Spoiler alert : pas de miracle, il va falloir se retrousser les manches et y passer du temps.

Écrire le test avant le code

Nous avons observé un phénomène intéressant : si nous demandons à une IA de développer un script qui teste de façon automatique le code qu'elle vient d'écrire, celle-ci sera tentée d'écrire un script qui valide le code, quitte à intégrer les mêmes erreurs. Une façon d'atténuer cet effet est de commencer par écrire le script du test, puis de coder dans un deuxième temps. Concrètement, nous avons développé un agent IA spécialisé dans la conception de nouvelles fonctionnalités. Cet agent reçoit le prompt de départ « je voudrais que l'appli clignote en jaune quand elle perd le réseau ». Son premier objectif va être de préciser la demande, en posant des questions de clarification : uniquement réseau Wi-Fi, ou réseau mobile ? Ou les deux ? Que fait-on lors d'une micro-coupure de quelques millisecondes ? Si l'utilisateur passe volontairement en mode avion, ça compte comme une perte de réseau ? Et ainsi de suite. Cela oblige le demandeur à être précis sur ce qu'il veut, à éliminer un maximum d'ambiguïtés, et l'IA peut alors développer un script de tests qui répond exactement à la demande. Une fois ce script écrit, on l'exécute une première fois : sans surprise, tous les résultats sont rouges, puisque la fonctionnalité n'existe pas encore. Mais maintenant on est prêt : quand l'IA livrera la fonctionnalité, on exécutera le script et l'on saura immédiatement si le code livré répond bien à la demande. Et cerise sur le gâteau, on pourra réexécuter ce script autant de fois que l'on voudra. À chaque évolution future de l'application, on pourra vérifier de façon quasiment instantanée que rien n'a été cassé.

Chaque test doit être développé par l'IA et vérifié par l'humain. C'est la meilleure façon de garantir sa fiabilité.

Quatre niveaux de tests, quatre regards

Chez Ping Europe, c'est la méthode que nous appliquons. Et ça fonctionne ! Nous bénéficions aujourd'hui d'une batterie de tests automatiques qui couvre quasiment tous les cas. Pour optimiser leur efficacité, nous les avons répartis en plusieurs catégories. Chaque catégorie se focalise sur un aspect et « voit » ainsi ce que les autres ne voient pas. Voici ces catégories :

  • Cohérence (quelques secondes) : typiquement, ce type de tests vérifie que le site vitrine respecte les exigences des moteurs de recherche pour être référencé, ou encore que tous les éléments graphiques de l'application sont conformes à notre modèle de référence. Sur les 3 derniers mois, ce contrôle a détecté une seule incohérence : il s'agissait d'un fichier de configuration du site vitrine ping-europe.org. C'est peu de chose, mais le coût des tests étant quasi nul, ce serait dommage de s'en priver.
  • Interface (2 006 tests en un peu plus d'une minute) : ces tests simulent des clics dans une version virtuelle de l'application pour vérifier son comportement. En trois mois, ces tests ont attrapé un peu moins de vingt régressions avant qu'elles n'atteignent un utilisateur. Par exemple, lorsque l'admin d'un groupe nommait admin un autre membre du groupe, celui-ci ne voyait pas le bouton permettant d'inviter un nouveau participant.
  • Serveur (près de 300 tests en quelques secondes) : ils font dialoguer des comptes fictifs après chaque mise en ligne d'essai. Sur les trois derniers mois, ils ont détecté 9 problèmes de messages ou de synchronisation, par exemple lorsqu'un utilisateur essayait d'envoyer une vidéo dépassant la taille limite de 75 Mo : il ne recevait aucun message d'erreur, la requête échouait silencieusement.
  • Vrai téléphone (71 scénarios, plus de 2 heures d'exécution) : un script pilote un téléphone réel : il ouvre des conversations, reçoit des photos et ferme l'application en plein milieu. On ne le lance qu'avant une mise en production, car c'est le plus lent des quatre. Ce mois-ci, il a trouvé trois anomalies que les 2 006 tests de l'interface ne voyaient pas : un avatar non mis à jour, un sondage affiché sans le nom de l'expéditeur, et un effet de bord lorsque l'utilisateur supprimait un message dans l'historique.

Et bien sûr, notre dernière source pour identifier des anomalies, ce sont nos gentils utilisateurs, qui prennent le temps de nous remonter les problèmes qu'ils détectent. Il s'agit souvent de conditions très particulières qu'il ne serait pas raisonnable d'essayer d'anticiper, comme une couverture réseau aléatoire, ou un modèle de téléphone rarissime (acheté à l'étranger, par exemple).

Les tests d'aujourd'hui permettront d'innover demain

Cet outillage et ces processus sont la clé de voûte de notre croissance. C'est bien sûr une façon de s'assurer que nos utilisateurs ont un produit fiable entre les mains, mais c'est aussi pour nous un socle solide sur lequel nous pouvons nous appuyer pour innover. Notre roadmap annonce des défis techniques très ambitieux (chiffrement résistant aux ordinateurs quantiques, envoi de messages directement entre deux téléphones sans passer par le réseau opérateur, version de l'application pour ordinateurs, etc.), et elle serait totalement irréaliste sans ses outils.