Fleet — les dix domaines

Ce que Fleet fait, domaine par domaine.

En détail

1. Fabriquer — l'image de l'appareil

Une image, c'est le contenu de la carte mémoire, prête à graver : système, réseau, scripts, identité, et si on le veut les applications elles-mêmes. On la décrit dans un formulaire, la plateforme la fabrique.

• Un formulaire, une image : langue, fuseau, réseaux WiFi, adresse, DNS, pare-feu, scripts.
• Rien à installer : une machine dédiée produit l'image, signée et compressée.
• Base officielle : le système vient des sources officielles, son empreinte est vérifiée.
• Valeurs héritées : zone, compte, flotte, appareil — le plus précis gagne, un champ vide hérite.
• Deux réseaux WiFi au minimum : celui du client et un secours, fusionnés depuis la flotte et la zone.
• Image de lot ou d'appareil : gravée sur plusieurs cartes, ou liée à une machine précise.
• Classes d'appareils : un profil nommé qui filtre les modules pour un parc hétérogène.
• Démarrage sans réseau : les applications peuvent être embarquées dans l'image.
• Recette figée : une fois créée, l'image ne bouge plus. Nouvelle configuration, nouvelle image.
• Cloisonnement : une clé par image — une carte compromise n'ouvre qu'elle.
• Outil de gravure pour Windows, macOS et Linux : il exclut le disque système, écrit, vérifie, éjecte.

2. Enrôler — identité, matériel, remplacement

L'identité d'un appareil naît dans son image et ne change plus. Le matériel qui la porte, lui, peut changer : l'historique suit.

• Clé cuite dans l'image : elle ne quitte jamais l'appareil et signe chaque échange.
• Enrôlement automatique : au premier signal, l'appareil est créé dans sa flotte et nommé.
• Suivi à travers les regravures : quatre cas arbitrés et tracés, du premier flash au transfert de matériel.
• Transfert entre comptes refusé par défaut.
• Historique en ajout seul des gravures et des liaisons, visible dans la fiche.
• Coupure immédiate : un matériel désactivé est refusé à l'authentification. Réversible d'un clic.
• Archivage doux : un appareil archivé garde son historique consultable.
• Référence externe : elle relie l'appareil à son point de vente dès son arrivée.

3. Déployer — version, aperçu, stratégies

La configuration de référence vit dans le dépôt Git du compte. Déployer, c'est pointer une version ; l'appareil va la chercher et se met à jour tout seul.

• Votre dépôt : GitHub, GitLab, Azure DevOps ou celui de la plateforme.
• Aperçu avant validation : un comparatif côte à côte montre ce qui change.
• Vérification du registre : chaque module est contrôlé pour chaque architecture avant l'envoi.
• Une image manquante bloque le déploiement, sauf confirmation explicite.
• La version déployée est celle lue à l'écran — jamais une version périmée par un délai de propagation.
• Trois stratégies : stricte avec retour arrière, tolérante pour le laboratoire, ou par étapes.
• Essai sur un seul appareil avant de généraliser, avec retour à la flotte en un clic.
• Historique complet : chaque déploiement garde son instantané, deux versions restent comparables.
• Nouvel essai à chaque signal de vie, sans abandon.

4. Configurer — cascade, réseau, pare-feu, secrets

Un seul modèle : la forme vient du dépôt, les réglages vivants de la base, les secrets du coffre-fort.

• Réglages en cascade : définis au niveau le plus pratique, hérités en dessous.
• Le serveur résout : l'appareil reçoit une configuration déjà calculée.
• Réseau par champ : le DNS s'applique à distance, l'adresse à la prochaine image.
• Pare-feu fermé par défaut : sans règle, tout ce qui entre est refusé.
• Son état constaté remonte dans la console : appliqué, échoué ou absent.
• Aucun secret dans la configuration : les accès sont émis à durée limitée à chaque signal de vie.
• Relus à chaud, sans redéploiement, et l'appareil est prévenu avant expiration.
• Disque chiffré et clé d'identité dans la puce : une carte reste illisible ailleurs.

5. Superviser — l'état vivant du parc

Voir sans se connecter : l'appareil remonte tout à chaque signal de vie, la console montre.

• Signal de vie toutes les minutes par défaut, réglable par flotte et par appareil.
• Ce qu'il remonte : version, température, mémoire, charge, adresses, état de chaque module.
• Les conteneurs réellement en marche — ce qui révèle un appareil resté sur une version périmée.
• Hors ligne détecté en trois minutes, de façon centralisée.
• Le motif d'un échec sans ouvrir de session : dernière erreur, modules en défaut, pare-feu constaté.
• Frise temporelle : on se place à une date et on lit l'état du parc à cet instant.
• Alertes : le passage hors ligne devient un événement routé vers courriel, SMS ou notification.

6. Intervenir — à distance et sur site

Aucune session permanente, aucune clé passe-partout. Chaque intervention a un auteur, une durée et une trace.

• Actions de secours : redémarrer l'appareil, l'agent, ou un module, depuis la console.
• Pilotable même sans canal ouvert : les ordres passent alors par la réponse au signal de vie.
• Console embarquée sur chaque appareil, servie sans ouvrir le moindre port.
• Elle fonctionne hors ligne, sur un réseau fermé.
• Accès technicien à durée limitée : de deux à quarante-huit heures, validé sans réseau par l'appareil.
• Un poste Windows nu suffit : l'outil technicien embarque tout ce qu'il faut.
• Configuration par câble USB : une page locale règle WiFi, adresse et DNS, sans regraver.
• Chaque changement est testé et annulé s'il coupe la liaison.
• Scripts par phase : démarrage, arrêt, planifié, après déploiement, santé.
• Audit complet : chaque action s'exécute exactement une fois et reste tracée.

7. Mettre à jour — agent, système, résilience

Mettre à jour un parc sur le terrain, c'est surtout savoir revenir en arrière.

• Agent mis à jour à distance, par flotte ou par appareil.
• Retour arrière automatique si le premier signal de vie ne confirme pas.
• Correctifs de sécurité du système appliqués à distance, avec fenêtre de maintenance.
• Un appareil à la fois pour le cœur du système.
• Fonctionnement hors ligne : ce qui est collecté part au retour du réseau.
• Réparation réseau progressive, puis redémarrage — jamais pendant une transaction.
• Écritures minimales sur la carte : en régime établi, l'appareil n'écrit rien.

8. Développer — le cadre applicatif

Vos équipes écrivent le métier, pas la plomberie.

• Le contrat est imposé : la plateforme orchestre tout module nouveau sans adaptation.
• Échec explicite : une configuration manquante arrête, elle ne se devine pas.
• Dix modules de base : bus local, affichage, synchronisation, journaux, simulateur, et cinq points de départ.
• Trois modes d'exécution du même code : développement, conteneur, ou débogage dans votre environnement.
• Un appareil virtuel dans le cloud rejoint la flotte comme un vrai — développer sans matériel.
• Débogage natif, y compris sous Windows sans sous-système Linux.
• Six langages, avec une bibliothèque commune et une parité imposée entre eux.
• Un dépôt autonome par partenaire, sans accès au cœur.
• Code protégé : les binaires distribués sont obfusqués, les sources ne sont jamais dans une image.

9. Gouverner — comptes, équipes, accès, zones

Qui voit quoi, qui peut quoi, et où vivent les données.

• Le compte est le périmètre : hors de lui, la réponse est « introuvable », pas « interdit ».
• Équipes et rôles : lecture pour les membres, modification pour l'administrateur, jusqu'au champ.
• Toute politique inconnue échoue fermée.
• Accès jamais affichés : ils sont résolus à l'identité de l'appelant, et chaque action remonte à une personne.
• Authentification d'entreprise : l'utilisateur est provisionné au premier accès, comme simple membre.
• Zones mutualisée ou dédiée, au choix par flotte — un compte peut mélanger les deux.
• Tâches longues suivies en direct : génération d'image, constructions, provisionnement.
• Journal en ajout seul : chaque trace résout à une identité nommée.

10. Trois types d'appareils