J’ai mis à jour en version 2.0.0 et publié sur npm une bibliothèque de graphiques React Native que j’avais créée il y a 9 ans. La majeure partie de cette mise à jour a été réalisée par un agent IA, et je partage ici le processus.
D’abord, une présentation de la bibliothèque. Comme son nom l’indique, l’identité de react-native-pure-chart est le mot « pure ». Elle n’utilise ni react-native-svg, ni ART, ni même Skia, devenu le standard aujourd’hui, et dessine des graphiques en ligne/barres/camembert uniquement avec les composants View/Text natifs de RN. Le principe de rendu est le suivant : la distance et l’angle entre deux points de données sont calculés avec la trigonométrie, puis une View fine et allongée est tournée via un transform rotate pour lui donner l’apparence d’un segment de ligne, et l’ensemble du graphique est construit en assemblant ces morceaux. La valeur clé, c’est l’absence totale de dépendances : pouvoir l’utiliser avec une seule commande npm install, sans avoir à lier une bibliothèque de dessin native ni craindre qu’un pod install casse la build. À son apogée, elle faisait 2 000 téléchargements hebdomadaires sur npm, était utilisée dans environ 820 projets et comptait 289 étoiles. Ensuite, elle a été laissée à l’abandon pendant 9 ans, au point qu’on ne savait même plus si elle fonctionnait encore avec les versions récentes de RN.
Par chance, il me restait un compte IA dont la limite allait bientôt être réinitialisée, alors j’ai laissé un prompt pendant la pause déjeuner.
« J’ai déjà fait le git clone, fais en sorte que ça fonctionne correctement dans l’environnement expo/RN actuel. Réfère-toi à la documentation du harness. »
Ici, le « harness » désigne un environnement d’auto-validation que j’avais préparé à l’avance. Il permet de piloter directement un simulateur iOS et un émulateur Android avec un outil mobile e2e comme Maestro, de prendre des captures d’écran et de vérifier le résultat du rendu. C’est là que se trouve le point clé de ce travail.
Pour faire fonctionner une base de code RN vieille de 9 ans dans l’environnement expo/RN actuel, il y a beaucoup de choses à retoucher. Les anciennes façons d’écrire les composants et les API de l’époque sont encore présentes, donc il ne s’agissait pas d’une simple mise à niveau de version, mais en pratique d’un refactoring de modernisation. Ce genre de travail n’est pas particulièrement difficile point par point, mais il y a énormément d’éléments, et à chaque correction il faut vérifier sur l’interface réelle que rien ne s’est cassé. C’est donc le type de tâche qui prend beaucoup de temps si un humain s’en charge directement.
Pendant que je faisais autre chose, l’agent a tourné en boucle pendant plusieurs heures. Il modifiait le code, lançait l’application dans le simulateur et l’émulateur, manipulait les écrans via l’e2e, prenait des captures d’écran, évaluait les problèmes de rendu à partir de ces captures, puis modifiait à nouveau le code. Ce qui compte, c’est que cette validation ne s’arrêtait pas aux erreurs de compilation ou au simple passage des tests. Pour une bibliothèque de graphiques, même si la build réussit, c’est un échec si les lignes sont décalées ou si les axes glissent. Comme la bonne réponse était « ce qui s’affiche à l’écran », cette boucle de régression visuelle basée sur des captures a comblé ce que les tests unitaires ne pouvaient pas vérifier.
Le plus grand changement de cette version est la prise en charge des graphiques en courbe (smooth line). En réalité, il y a 9 ans, la bibliothèque ne savait pas les gérer. Une ligne droite se fait en tournant une seule View, mais une courbe doit être découpée en petits segments, dont il faut calculer les coordonnées et les angles pour l’approximer avec de courts traits. À l’époque, je n’avais pas réussi à résoudre le problème des raccords très légèrement coupés ou anguleux entre les segments, et je n’avais donc pas intégré la fonctionnalité. Cette fois, l’agent ne s’est pas contenté de vérifier des captures d’écran globales : il a aussi réalisé des captures zoomées des zones où il soupçonnait des ruptures dans la courbe. Il a ensuite ajusté les valeurs des variables utilisées pour calculer les coordonnées et les angles des segments, relancé le rendu, zoomé à nouveau pour vérifier, puis répété le cycle. Quand un humain répète lui-même une telle boucle de tuning — changer les paramètres puis inspecter visuellement le résultat — il finit généralement par accepter un compromis à un moment donné. L’agent, lui, a continué jusqu’à convergence, et au final un graphique en courbe fluide a été ajouté comme nouvelle fonctionnalité. Autrement dit, une fonction que je n’avais pas réussi à implémenter il y a 9 ans a finalement été intégrée cette fois.
Au final, la compatibilité avec l’environnement expo/RN actuel, la prise en charge des graphiques en courbe, la mise à jour des captures d’écran des graphiques dans le README, ainsi que la build et la publication de npm 2.0.0 ont toutes été menées à bien. C’est une mise à jour après 9 ans.
Voici ce que j’ai retenu de ce travail. Je me suis mis à penser que le principal goulot d’étranglement du coding avec agents se situe moins dans les performances du modèle que dans l’environnement de validation. Dès lors qu’un harness permet à l’agent de vérifier lui-même le résultat, il peut converger jusqu’à la qualité visuelle sans revue humaine. Cela s’est révélé particulièrement efficace pour des projets comme les bibliothèques UI, où la bonne réponse se trouve à l’écran, grâce à la combinaison entre manipulation e2e et évaluation par captures d’écran. Les tâches comme la modernisation de legacy, peu difficiles mais coûteuses en vérifications répétées, semblent être une catégorie particulièrement adaptée à déléguer à un agent.
GitHub: https://github.com/oksktank/react-native-pure-chart
npm: https://www.npmjs.com/package/react-native-pure-chart
Aucun commentaire pour le moment.