Yaëlle Vinçont

J'ai quitté l'IRIF, et je suis maintenant AGPR (agrégée préparatrice) à l'ENS Rennes. J'y enseigne au sein de la préparation à l'agrégation d'informatique, et j'effectue ma recherche au sein de l'équipe SUSHI (ex-CIDRE).

Vous pouvez me joindre à l'adresse yaelle.vincont(at)ens-rennes.fr.

Avant cela, j'étais en ATER à l'IRIF (Université Paris Cité), après une thèse au LMF et au CEA List (Université Paris-Saclay). J'ai aussi obtenu l'agrégation d'informatique en 2022.

Pendant ma thèse, j'ai travaillé sur la création d'une méthode d'analyse de traces, inspirée de l'exécution symbolique dynamique, dans le but de guider de la génération automatique de tests.

L'idée clé était qu'en analysant les traces, nous pouvons identifier des contraintes simples sur les entrées utilisateurs, telles que tout cas de test satisfaisant ces contraintes suivra la trace, jusqu'à un certain point. Nous avons ensuite modifié un outil de fuzzing (AFL), qui cherche (et trouve) des vulnérabilités dans des programmes en générant des cas de tests (plus ou moins) aléatoirement, de façon à ce que les cas de tests qu'il génère satisfassent les contraintes trouvées par l'analyse.

Ainsi, les contraintes trouvées par l'analyse symbolique (implémentée comme un greffon de la plateforme BinSEC) permettent de guider la génération des tests par AFL contraint, par exemple pour découvrir de nouveaux chemins, ou créer des cas de tests explorant des chemins intéressants.

Cette année, je travaille sur la détection automatique de “flaky” tests.

La création de tests unitaires fait partie du cycle de développement de (en théorie) toute application. Souvent, on met en place un système permettant de rejouer automatiquement tous les tests unitaires à chaque modification de l'application, par exemple l'intégration continue dans git qui fait cela pour chaque commit.

Cependant, que ce passe-t-il si un test passe 90% du temps… et échoue 10% du temps? Non pas parce que le code qu'on a ajouté en a changé le comportement, mais simplement parce que son résultat est non déterministe. Par exemple s'il dépend d'un générateur de nombre aléatoire, ou de l'ordre d'exécution de fils concurrents… C'est ce qu'on appelle un “flaky” test.

La sécurité logicielle, que ce soit trouver des failles en analysant le code haut niveau avec des méthodes formelles, ou le code assembleur avec du reverse engineering.

• IP1: Initiation à la Programmation (Python), CMTD+TP, en L1 MIASHS

• IO2: Internet et Outils, TP, en L1 Informatique
• SI6: Sécurité Informatique, cours, en L3 Informatique
• PR6: Programmation Réseaux, TP, en L3 Informatique

Signature de ma clé PGP publique: 5809 F10E 6DE1 3CD9 372A 192B AE6D 4B57 CE1F 9570