NexmeshFonctionnalités
Ce qu’elle fait à votre place
Écrire une préparation, la jouer sur tout un parc, tenir le cap quand un appareil lâche, et garder la preuve. Un service l'étend le jour où l'atelier compte plus d'un poste.
01Écrire
Écrivez-la une fois, relisez-la dans un an
Une préparation est un fichier YAML, pas un script. Elle se lit, elle se commente, elle se compare d'une version à l'autre, et elle se copie d'un poste à l'autre avec tout ce qui va avec.
- 01
Un seul schéma pour tout
Un fichier décrit ce qu'un scénario accepte. Il valide avant l'exécution, complète pendant que vous tapez, et construit les formulaires de l'éditeur visuel. Un champ ajouté apparaît aux trois endroits le même jour.
- 02
Deux éditeurs, un seul fichier
Composez le déroulé à la souris, bloc par bloc, ou tapez le YAML dans Monaco, validation à la frappe comprise. L'éditeur visuel modifie l'arbre du document au lieu de le réécrire : vos commentaires et votre mise en forme survivent au passage.
- 03
Des valeurs demandées au lancement
Un nom de poste, un profil à choisir, un mot de passe. Le scénario les déclare, l'écran de lancement les demande, un CSV peut les fournir.
- 04
Le format avance sans casser
Chaque scénario porte le numéro du format qui l'a écrit. Un fichier plus ancien est migré à la lecture, directement sur le document, donc il garde ses commentaires. Il n'est réécrit sur le disque qu'au moment où vous enregistrez.
- 05
Le manuel est dans la fenêtre
Manuel d'usage et référence complète du format : chaque type de step, chaque condition, chaque variable, avec son exemple. La référence est générée depuis le schéma, elle ne peut donc pas prendre de retard sur lui.
- 06
Trois exemples commentés
Un dossier de travail neuf en reçoit trois à lire. Ouvrez-les, dupliquez-les, supprimez-les : ils ne reviendront pas.
02Jouer
Tous les appareils à la fois
Le scénario part une fois par appareil, chacun avec ses variables et ses captures. En série ou en parallèle, avec le nombre d'appareils simultanés que vous fixez.
- 01
USB, Wi-Fi, Ethernet
Les appareils apparaissent dès qu'ADB les voit. Repris sans fil, un téléphone reste le même téléphone : c'est son numéro gravé qui l'identifie, pas l'adresse réseau qui changera au prochain bail.
- 02
Des contrôles avant de partir
Batterie, espace libre, état de l'écran, ou une commande à vous. Ils passent sur chaque appareil avant que quoi que ce soit ne parte, et vous décidez s'ils préviennent ou s'ils bloquent le départ.
- 03
La simulation
Parcourez tout le déroulé sans qu'une commande parte. L'ordre des steps, les branchements, les boucles : vérifiés sans un appareil sous la main. Et rien ne remonte au service, puisqu'une simulation n'a rien préparé.
- 04
Des lots de valeurs
Un CSV donne ses colonnes aux variables du scénario. Une ligne par numéro de série, ou au fil de l'eau : chacun prend la première ligne libre, qui passe à « servie » et ne ressortira plus.
- 05
Une console de progression
Une colonne par appareil, une ligne par step, son résultat en face : réussi, échoué, ignoré. Et vous continuez malgré une erreur quand c'est ce que vous voulez.
- 06
Des relevés
Un collecteur lit une information sur l'appareil et lui donne une colonne. En fin d'exécution, un CSV à en-têtes stables atterrit dans le dossier du scénario, prêt pour la requête Excel que vous y brancherez.
03Tenir
Le lot tient, même quand ça tourne mal
Trois mécanismes protègent l'exécution. Chacun existe parce qu'on a payé son absence au moins une fois.
- 01
Le lot ne reste jamais suspendu
Chaque appel ADB a son délai : une minute pour une commande, dix pour un transfert, réglable par scénario. C'est aussi ce qui fait qu'Annuler répond tout de suite.
- 02
Un appareil qui s’en va le dit
La liste des appareils est relue entre deux steps et pendant chaque commande. Débranché, un appareil arrête sa propre exécution en disant lequel il est et dans quel état il reste. Les autres terminent.
- 03
Rien ne disparaît sans trace
Une erreur que rien n'a rattrapée part dans un fichier d'incidents, à côté des réglages. Une fenêtre qui meurt est simplement rechargée : l'exécution, elle, ne vit pas dans la fenêtre.
- 04
Les réglages se migrent aussi
Le fichier de réglages porte sa génération et se met à jour tout seul. Plus récent que l'application, il n'est pas touché : une version antérieure lancée par erreur n'efface pas ce qu'elle ne comprend pas.
04Garder
Ce qui s’est passé reste écrit
Un journal répond des semaines plus tard, et depuis un autre poste, à la question qu'on finit toujours par poser : qu'a-t-on fait, sur quel appareil, et est-ce que ça a marché ?
- 01
Un dossier par scénario
Le déroulé, les pièces que vous lui joignez, ses CSV d'entrée, ses relevés et ses journaux vivent ensemble. Un scénario se copie d'un poste à l'autre avec son histoire.
- 02
Une fenêtre d’historique
Relisez les exécutions passées sans quitter l'application : le journal tel qu'il a été écrit, les appareils concernés, le résultat, le relevé produit.
- 03
L’inventaire du matériel
Avec un service en face, chaque appareil préparé rejoint un inventaire : son modèle, sa version d'Android, le nombre de préparations qu'il a subies et la dernière en date. Désigné par son numéro gravé, pas par une adresse réseau.
- 04
Des remontées qui attendent leur tour
Le journal part une fois l'exécution terminée et ne fait jamais échouer quoi que ce soit. Ce qui n'est pas parti repartira au passage suivant : un service injoignable ne doit pas gâcher une préparation réussie.
05En option
Le service et sa console web
Un poste d'atelier isolé se suffit. Le service arrive quand les postes se multiplient, et avec lui une console qu'on ouvre dans un navigateur.
- 01
Vos scénarios déposés
Un poste envoie son dossier, le service garde cinq versions par fichier. Un fichier inchangé n'écrit rien : redéposer toutes les heures ne fabrique pas une version par heure.
- 02
Personne n’écrase personne
Le dépôt annonce la version dont il part. Si ce n'est plus la dernière, le service refuse plutôt que de fusionner : deux YAML qui ont divergé ne se réconcilient pas tout seuls. Un texte identique, lui, passe toujours.
- 03
Des fichiers de données préparés une fois
Un lot de licences, une liste de noms de postes : écrivez-les dans la console, chaque poste les reçoit avec le scénario. Un lot entamé ne se remplace pas, sinon des licences déjà distribuées reviendraient au tirage.
- 04
Un magasin d’applications
Vos APK rangés par empreinte : envoyé deux fois, un fichier n'occupe qu'une place. Un poste ne télécharge que ce qui lui manque, et ce qu'un scénario réclame se déduit de son texte, steps désactivés compris.
- 05
Des comptes et des organisations
Des rôles, une identité visuelle par organisation, un second facteur TOTP avec ses codes de secours. Tout est fermé par défaut : c'est l'ouverture d'une route qui se voit dans le code, jamais son oubli.
- 06
Le stock revalidé
Le format avance, donc un scénario valide au moment du dépôt ne l'est pas pour toujours. La console rejuge le stock et retient le verdict : vous savez ce qui demande une reprise avant de le découvrir au lancement.
06Autour
Le reste, limites comprises
- 01
Windows, et des appareils qu’ADB voit
L'application se livre en installeur NSIS pour Windows. Pas de version macOS ni Linux, et pas d'iOS en face : Nexmesh pilote ce qu'ADB sait joindre. Le service et sa console, eux, se livrent en images conteneurisées.
- 02
Français et anglais
Interface, manuel, messages d'erreur et journal. Deux catalogues tenus en parité, et des tests qui refusent une clé présente d'un seul côté.
- 03
Les nouveautés, une fois
Le premier lancement après une mise à jour ouvre ce qui a changé depuis la version que vous aviez, et rien de plus. L'historique complet reste accessible depuis la rubrique À propos.
- 04
Le format, publié à part
Le format des scénarios et son analyse forment un paquet npm à eux seuls, sans Electron ni ADB. C'est le même code qui juge un fichier sur le poste et sur le service : vous ne pouvez pas obtenir deux réponses pour un même fichier.
07Le vocabulaire
Trente-trois façons d’agir sur un appareil
Un step, c'est une action. Les voici sous le nom que vous taperez dans le fichier. L'éditeur visuel propose les mêmes, avec leurs champs et leur description.
Gestes à l’écran
- tap
- tapOn
- longPress
- swipe
- key
- text
Appuyer sur un point ou sur un libellé lu à l'écran, balayer, envoyer une touche matérielle, saisir du texte.
Applications
- install
- uninstall
- launchApp
- forceStop
- clearData
- packageState
Installer un APK du dossier commun et lui accorder ses permissions au passage, lancer, arrêter, effacer les données, activer ou désactiver un paquet.
Réglages et système
- setting
- svc
- reboot
- intent
- broadcast
- shell
Écrire un réglage, basculer le Wi-Fi ou les données mobiles, redémarrer, émettre une intention. Et quand rien de tout ça ne suffit, une commande shell dont vous capturez la sortie.
Fichiers
- push
- pull
- writeFile
Déposer un fichier du poste sur l'appareil, en rapatrier un, ou écrire sur place un gabarit dont les variables ont été remplacées.
Attendre
- wait
- waitFor
- waitForDevice
Une pause fixe, l'attente d'une condition comme un texte à l'écran ou une sortie de commande, ou le retour de l'appareil après un redémarrage.
Conduire le déroulé
- if
- repeat
- call
- return
- end
- fail
- log
- collect
- markRowDone
Brancher sur une condition, répéter, appeler un bloc écrit une fois et réutilisé partout, s'arrêter volontairement, écrire au journal, relever une valeur.
Comment c’est construit
Le journal raconte les décisions de conception, et surtout ce qui les a rendues nécessaires. C'est là qu'on voit si un produit a été pensé ou assemblé.