Liste de validation avant la mise en production de l’intégration d’AI Agent à Univer : régression des navigateurs Mac en 2026

La documentation d’Univer décrit des fonctions d’édition et des possibilités d’extension, mais elle ne prouve pas que votre intégration d’AI Agent fonctionne dans votre application : avant la mise en production, vérifiez l’état des documents, les limites d’action, les interactions sur Mac, la reprise après incident et les preuves de régression. Cette démarche s’applique aux équipes qui ont défini leurs navigateurs et leurs environnements cibles ; les conclusions doivent rester limitées aux combinaisons effectivement testées.

Univer : cette liste aide à examiner les actions de l’agent sur l’éditeur et à en délimiter les effets.
Ingénieurs QA : elle fournit une base pour organiser la régression sur les navigateurs Mac et consigner les échecs.
Responsables techniques : elle aide à vérifier les permissions, la reprise et la qualité des éléments de preuve.

Délimiter la validation à partir des parcours réels

Commencez par choisir des parcours que les utilisateurs accomplissent réellement dans le produit : modifier une cellule, mettre en forme une plage, corriger un passage dans un document ou préparer une présentation. Les capacités disponibles varient selon les modules retenus et les extensions mises en œuvre ; la documentation officielle d’Univer constitue la limite de ce qui peut être présenté comme fonction documentée, pas une garantie concernant votre branche de code ni votre connexion à un agent. Le dépôt officiel d’Univer et ses instructions de démarrage pour les feuilles de calcul sont à consulter pour vérifier les composants et le parcours d’édition réellement intégrés.

Pour chaque parcours, écrivez les étapes dans l’ordre où elles se produisent : l’utilisateur formule sa demande, l’agent propose ou exécute une action, l’éditeur affiche le changement, puis l’utilisateur vérifie ou annule le résultat. Une étape présentée comme automatique doit être confirmée dans votre propre intégration. Si le système nécessite une validation humaine, incluez-la au scénario au lieu de la traiter comme un détail d’interface.

Parcours à comparer	Déclenchement et responsabilité	Critère de décision
Édition pilotée par l’utilisateur	L’utilisateur modifie directement le contenu ; l’éditeur applique son interaction.	Vérifier que l’action habituelle reste possible lorsque l’agent n’est pas sollicité.
Action proposée par l’agent	L’agent prépare une modification que l’utilisateur doit examiner ou accepter.	Contrôler que la proposition et son effet sont visibles et peuvent être refusés.
Action exécutée par l’agent	L’agent modifie le document par la voie effectivement implémentée dans le produit.	Confirmer que l’action ne dépasse pas les droits accordés et que son résultat est vérifiable.

Quelles opérations faut-il couvrir après une intégration d’AI Agent dans Univer ? Au minimum, retenez les opérations qui représentent un risque ou un usage central de votre produit : lecture ou modification de données, application d’un format, création ou suppression de contenu, et passage entre l’agent et l’interface. La sélection doit correspondre aux commandes réellement disponibles ; ne déduisez pas d’une démonstration qu’une commande voisine est prise en charge.

Pour les feuilles, la documentation des fonctions principales peut aider à choisir les opérations d’édition à examiner. Si l’intégration s’appuie sur des commandes personnalisées, la documentation sur l’extension des commandes aide à identifier la frontière technique concernée. Ces références décrivent Univer ; elles ne certifient ni votre logique de permission ni le comportement de l’agent.

Contrôler l’état du document avant et après chaque action

Une action ne peut pas être acceptée sur la seule foi d’un message de confirmation de l’agent. L’équipe doit pouvoir comparer l’état précédent et l’état obtenu dans l’éditeur, puis distinguer le contenu changé, le format modifié et le statut d’enregistrement. Pour chaque parcours retenu, consignez une capture ou une autre preuve lisible avant l’action et une preuve après celle-ci. Lorsque le produit affiche un état d’enregistrement, notez-le explicitement ; ne confondez pas l’affichage du nouveau contenu avec sa persistance effective.

État examiné	Preuve à conserver	Résultat à vérifier
Contenu initial	Capture, export ou relevé représentatif avant l’action.	Les données utiles et leur emplacement sont identifiables.
Contenu après exécution	Vue de l’éditeur après l’action, complétée si nécessaire par un relevé comparable.	Le changement correspond à la demande et n’altère pas d’autres éléments sans autorisation.
Format et structure	Capture faisant apparaître les cellules, styles, sections ou diapositives concernés.	La mise en forme attendue est conservée ou modifiée comme prévu.
Enregistrement	Indication de l’interface et vérification après le mécanisme de sauvegarde prévu par le produit.	L’état obtenu est bien celui que l’application considère comme enregistré.
Refus ou annulation	Vue avant et après le refus ou l’annulation.	Le contenu revient à l’état attendu, sans action supplémentaire non demandée.

Concevez séparément un scénario réussi, un scénario annulé et un scénario de répétition. Dans ce dernier, l’équipe relance la même requête ou reproduit le même événement et contrôle si le système ajoute une seconde modification, écrase le résultat précédent ou détecte le doublon. Le résultat acceptable dépend du comportement prévu par votre produit : l’objectif du test est de révéler ce comportement et de le confronter aux exigences, pas d’imposer une règle universelle.

Comment vérifier qu’une modification de tableau par l’agent est correcte ? Comparez les valeurs concernées, les cellules voisines utiles, le format et l’état d’enregistrement avec les preuves prises avant l’action. Lorsque la demande est ambiguë, vérifiez aussi que l’agent demande une précision ou propose un résultat à confirmer, selon le fonctionnement réellement défini par l’application.

Séparer les autorisations prévues des protections effectivement testées

Une spécification de permission n’est pas une preuve d’application correcte. Écrivez les droits attendus pour chaque profil, puis essayez de les franchir depuis l’interface ou le parcours d’agent testé. Par exemple, un agent censé modifier une zone précise ne doit pas provoquer un changement hors de cette zone simplement parce que la requête le suggère ; un profil en lecture seule ne doit pas obtenir une capacité d’édition par un chemin secondaire.

Dans la fiche de contrôle, distinguez les faits observables de l’intention de conception. « La suppression doit demander une confirmation » est une exigence ; « une confirmation s’affiche, le refus interrompt l’action et aucune suppression n’apparaît dans le document » est un résultat vérifié. Pour toute action sensible, relevez l’acteur, la demande, la confirmation demandée, la décision de l’utilisateur et l’état final du document. En cas d’échec, vérifiez que l’opération s’arrête au lieu de poursuivre avec les étapes restantes.

Une permission affichée dans l’interface ne suffit pas : le test doit confirmer qu’une action non autorisée est refusée ou interrompue et que le document n’a pas subi de modification indirecte.

Prévoyez également les actions concurrentes. Si une personne modifie le document pendant qu’un agent prépare une opération, contrôlez ce que l’agent observe au moment d’agir et ce que l’éditeur affiche ensuite. N’affirmez pas que les modifications concurrentes sont gérées automatiquement à moins que ce comportement soit documenté pour votre intégration et confirmé par un test.

Examiner les interactions propres aux navigateurs Mac

La régression doit s’effectuer dans les navigateurs et sur les environnements que votre produit annonce réellement prendre en charge. Notez le système, le navigateur, sa version, le mode de lancement de l’application et les dépendances pertinentes au moment du test ; un résultat sur un poste donné ne démontre pas la compatibilité avec toutes les installations Mac. Le moteur WebKit proposé par un outil d’automatisation n’équivaut pas, à lui seul, à une validation du navigateur Safari installé sur un poste utilisateur.

Cible de vérification	Contrôles à effectuer	Éléments à consigner
Focus et clavier	Entrée et sortie des champs, navigation entre éditeur, commandes et panneau d’agent, raccourcis utilisés par le produit.	Élément actif, séquence de navigation, raccourci essayé et résultat visible.
Défilement	Défilement du document, d’un panneau latéral et d’une fenêtre modale ; vérifier que la zone attendue bouge.	Position de départ, zone sollicitée et contenu obtenu après l’action.
Fenêtres et panneaux	Ouverture, fermeture, superposition et interaction avec les menus de confirmation.	Capture de l’interface et réaction à chaque commande testée.
Dimensions d’affichage	Mise en page du document, panneau de l’agent et commandes lorsque la fenêtre change de taille.	Dimensions enregistrées et éventuels éléments masqués ou inaccessibles.
Exécution automatisée	Comparaison entre les tests automatisés et la vérification dans le navigateur réellement ciblé.	Outil, moteur ou navigateur, version et limites connues du scénario automatisé.

Pour le clavier, prenez comme repère le critère WCAG relatif à l’ordre du focus, identifié comme 2.4.3 : l’ordre de navigation doit conserver une signification et une opérabilité. Ce critère sert à structurer l’observation ; il ne remplace pas l’évaluation du parcours complet de votre application.

Les navigateurs pris en charge par les outils de test peuvent être examinés dans leur documentation sur les navigateurs et moteurs. Cette référence distingue trois moteurs pris en charge par l’outil : Chromium, Firefox et WebKit. Ce chiffre décrit les moteurs disponibles pour cette automatisation, et non le nombre de navigateurs Mac validés pour votre service. Pour examiner les éléments affichés et les erreurs côté page, utilisez les outils d’inspection des pages Web dans le cadre du navigateur effectivement visé.

Que doit couvrir une régression de navigateur sur Mac ? Vérifiez le focus, les raccourcis réellement utilisés, le défilement, les menus et fenêtres, ainsi que la disposition de l’éditeur et du panneau de l’agent. Ajoutez au parcours les usages créatifs lorsque votre produit les propose : une présentation avec contenus visuels, une mise en page de document ou des éléments audio et vidéo intégrés peuvent solliciter des contrôles différents d’une simple saisie dans une cellule.

Simuler les interruptions et vérifier le comportement de reprise

Une requête peut être interrompue après son lancement, pendant l’attente d’une réponse ou au moment où le résultat doit être appliqué. Testez ces cas dans un environnement où les conséquences sont maîtrisées : actualisation de page, perte de connexion, retour d’un onglet en arrière-plan et modification de l’état du document pendant l’attente. Pour les journaux, conservez le moment de l’incident, l’action en cours et la réponse de l’interface, sans inclure de données sensibles.

L’API de visibilité de page distingue deux états, visible et hidden, comme le précise la référence sur l’API Page Visibility. Servez-vous de cette distinction pour construire un cas reproductible quand le produit suspend, continue ou reprend une tâche après un changement d’onglet ; ne présumez pas du comportement de votre agent à partir de la seule API.

À chaque interruption, vérifiez les mêmes points : l’utilisateur sait-il si l’opération est encore active ; l’application permet-elle d’arrêter ou de relancer la tâche ; l’état du document reste-t-il compréhensible ; une relance produit-elle un doublon ou une modification supplémentaire ? La règle de reprise doit être définie par le produit. Si la tâche ne peut pas reprendre sans risque, l’application doit l’indiquer et orienter vers une vérification manuelle plutôt que laisser croire que le résultat est complet.

La documentation sur les nouvelles tentatives de tests aide à distinguer une relance automatisée d’un résultat stable : une tentative réussie après un échec ne doit pas effacer l’information sur le premier échec. De même, les contextes de navigateur isolés permettent d’organiser des exécutions séparées ; cette isolation facilite la reproductibilité, mais ne prouve pas que les données de votre application sont isolées ou restaurables.

Comment vérifier la reprise après une interruption ? Reproduisez l’incident, observez l’état de la tâche et du document, puis essayez la relance selon le parcours prévu. Comparez le document à la preuve initiale et confirmez que l’application signale clairement une tâche interrompue, terminée ou à vérifier.

Constituer un dossier de validation exploitable

Une conclusion de test n’est réutilisable que si une autre personne peut retrouver son contexte. Utilisez une fiche par scénario et consignez au minimum l’identifiant du cas, l’environnement cible, l’état préalable, l’action lancée, le résultat attendu, le résultat observé, les preuves et le lien vers l’anomalie si nécessaire. Ajoutez la version du code et les versions du système et du navigateur effectivement relevées ; ne remplacez pas ces données par une mention vague comme « testé sur Mac ».

Champ de la fiche	Contenu à enregistrer	Utilité pour la décision
Identifiant du scénario	Nom stable lié au parcours et au risque examiné.	Permet de retrouver le cas dans les exécutions ultérieures.
Environnement	Système, navigateur, version, mode d’exécution et version de l’application.	Limite la conclusion à la combinaison effectivement vérifiée.
État préalable	Contenu et permissions avant l’action, avec preuve associée.	Permet de distinguer un défaut préexistant d’une régression.
Résultat attendu et observé	Comportement produit attendu, puis résultat réellement constaté.	Rend l’écart compréhensible pour l’équipe responsable.
Preuves et anomalie	Captures, journaux utiles et référence à la fiche de défaut, si elle existe.	Facilite le diagnostic et la vérification après correction.
Décision	Accepté, refusé ou à rejouer, avec justification selon le risque produit.	Conserve le raisonnement qui soutient la mise en production.

Organisez l’exécution comme une séquence de travail, et non comme une capture isolée :

• Définissez les parcours utilisateurs et les navigateurs inclus dans le périmètre annoncé.
• Préparez un document de test, des profils de permission et un état de référence.
• Exécutez les scénarios d’édition réussie, d’annulation et de répétition ; conservez les preuves avant et après.
• Rejouez les parcours sensibles sur chaque environnement Mac retenu, en notant les versions observées.
• Simulez les interruptions prévues et contrôlez la possibilité d’arrêt, de reprise ou de vérification manuelle.
• Ouvrez les défauts avec leurs éléments de preuve, puis rejouez les cas affectés après correction.
• Faites approuver la décision de mise en production au regard des risques et des exigences propres au projet.

Il n’existe pas de seuil de réussite unique valable pour tous les produits. L’équipe doit décider quels défauts bloquent la sortie, quelles fonctions peuvent être livrées avec une limitation connue et quelles preuves sont obligatoires pour les opérations sensibles. Un test réussi démontre seulement le comportement observé dans son environnement documenté ; après une évolution importante d’Univer, de l’intégration de l’agent ou du navigateur, rejouez les cas concernés au lieu d’étendre automatiquement la conclusion précédente.

Une équipe qui s’appuie uniquement sur le poste d’un développeur et une démonstration préparée risque de manquer les écarts de navigateur, de partager un environnement difficile à reproduire et de ne pas disposer d’un Mac libre au moment de la régression. À l’inverse, l’achat d’un Mac dédié convient davantage à des besoins permanents, à une charge soutenue ou à des tests nécessitant des interfaces physiques. Pour une régression ponctuelle, un environnement Mac loué via nuvcloud peut offrir une machine distincte du poste quotidien et simplifier l’organisation d’un créneau de test ; il ne remplace toutefois ni la définition des navigateurs pris en charge ni la collecte de preuves. Avant de planifier cet essai, consultez le centre d’aide nuvcloud pour préparer les modalités d’accès et vérifier que l’environnement correspond à vos scénarios. Si vous devez comparer les modalités selon la région concernée, consultez aussi les informations de commande pour l’est des États-Unis, puis retenez uniquement l’environnement qui correspond au navigateur et aux cas de test prévus.