VibeGuardQuand une fonction casse
Une modification dans Lovable a cassé une autre fonctionnalité. Que faire ?
Vous avez simplifié la modification des projets. Maintenant, un compte en lecture seule peut supprimer un document pendant un test. Avant de demander une nouvelle modification générale, décrivez ce défaut de façon précise et reproductible.
Confirmez la régression avec les mêmes conditions de départ
Une régression survient lorsqu’un comportement qui fonctionnait ne fonctionne plus comme prévu. Comparez la version actuelle à la dernière version qui fonctionnait, en conservant autant que possible le même rôle, les mêmes données de test et la même configuration.
La suppression accepte un compte en lecture seule.
Dans la version précédente, le même test était refusé et le document restait intact. Après la modification, l’opération réussit. C’est une preuve obtenue dans un test contrôlé, pas un relevé de l’activité d’une personne en production.
Si vous ne parvenez pas à reproduire le résultat précédent, gardez cette distinction : vous avez trouvé un défaut, mais vous n’avez pas encore établi quand il est apparu. Vérifiez les permissions, la configuration et les données initiales avant d’attribuer sa cause à une modification précise du code.
Évitez d’exposer vos clients à la version défaillante
Si la modification n’est pas encore publiée, suspendez sa mise en production pendant l’enquête. Si elle est déjà en ligne et présente un risque sérieux, évaluez le retour à une version qui fonctionnait et la restriction de l’action concernée.
Revenir à une version précédente du code n’annule pas forcément les modifications de la base de données et ne restaure pas les enregistrements supprimés. Vérifiez la compatibilité et les sauvegardes disponibles avant de décider. Utilisez des données jetables pour reproduire le problème.
Appuyez-vous sur les changements du code pour orienter l’enquête
Examinez dans GitHub les différences entre les deux versions. Commencez par le code impliqué dans l’action concernée : contrôles de permission, composants partagés, traitement des requêtes et politiques d’accès aux données.
Dans l’exemple du compte en lecture seule, cherchez un contrôle de rôle retiré d’une fonction de suppression partagée ou une politique d’accès modifiée. Ce sont des hypothèses à tester, pas des conclusions à supposer. Le bouton peut rester identique alors que le serveur accepte une requête qu’il refusait auparavant.
- Le défaut ne concerne-t-il qu’un rôle ou un espace de travail ?
- Se produit-il via l’interface, par une requête directe ou dans les deux cas ?
- Les données changent-elles réellement, ou l’interface annonce-t-elle seulement un succès ?
- Quels parcours voisins utilisent le code modifié ?
Transmettez à Lovable un signalement reproductible
« Cela ne fonctionne toujours pas » laisse trop de possibilités ouvertes. Décrivez la situation initiale, l’action exacte et le résultat attendu. Précisez ensuite le comportement correct que la correction doit préserver.
Dans l’espace de travail de test, connectez-vous avec un compte en lecture seule et tentez de supprimer un document existant. La version actuelle accepte l’opération ; la précédente la refusait. Le résultat attendu est une requête refusée, sans modification du document. Examinez l’autorisation de cette opération et ajoutez un test de régression. Préservez la possibilité de suppression pour le propriétaire. Vérifiez aussi que les membres d’une autre entreprise ne peuvent pas accéder au document.
Joignez les versions testées et les preuves pertinentes du défaut. Excluez les mots de passe, les jetons et les données personnelles des clients. Le signalement doit permettre de reproduire le problème sans accéder au compte d’un client réel.
Vérifiez la correction et conservez la règle
Rejouez le scénario initial après la correction. Vérifiez ensuite une action autorisée et la limite d’accès voisine. Dans cet exemple : le compte en lecture seule est bloqué, le propriétaire peut supprimer et un membre d’une autre entreprise ne peut ni lire ni supprimer le document.
Conservez ces attentes dans la suite de régression, associées à la règle métier qu’elles protègent. Si le modèle de permissions évolue volontairement, mettez à jour le comportement attendu de façon explicite au lieu de considérer tout nouveau résultat comme correct.
Le résultat recherché
Un défaut reproductible, une correction validée par la même vérification et un scénario conservé pour la prochaine publication. C’est plus utile qu’un simple message « corrigé » sans suite.