Outil gratuit
Autopilot Advisor
Quel scénario pour quelle population, et combien de techniciens ?
Décrivez vos populations de postes — pas des machines, des situations — et l'outil nomme le scénario Autopilot qui leur convient : V1 ou V2, pré-provisionné ou non. Il croise les deux axes de décision, la preuve d'appartenance et l'endroit où passe le temps, puis il chiffre ce que chaque scénario coûte en visites, en techniciens et en mois. Quand deux de vos réponses ne peuvent pas être vraies en même temps, il le dit plutôt que de trancher à votre place.
Aucune inscription, aucun cookie : ce que vous saisissez reste dans votre navigateur et s'efface quand vous fermez l'onglet — rien n'en sort. Seule la visite est comptée, par une mesure d'audience sans cookie qui ne vous identifie pas, décrite dans les mentions légales.
Le chantier
Ces trois nombres transforment un scénario en calendrier. Laissez-en un vide et l'outil dira ce qu'il ne peut pas encore calculer, plutôt que d'inventer une valeur.
Vos populations de postes
Une population, c'est un ensemble de machines qui partagent la même situation : le même type de matériel, la même exigence de preuve, la même contrainte de temps. Un parc physique et une ferme de VM ne sont jamais la même population, et c'est précisément pour cela qu'ils n'auront pas le même scénario.
Le plan
Les durées de visite utilisées ici sont des fourchettes tirées de l'expérience de déploiements comparables, ajustées par vos réponses. Elles ne remplacent pas un pilote : sur vingt à trente postes, la durée réelle s'écarte couramment de moitié dans un sens ou dans l'autre selon le socle, le réseau et le nombre d'applications bloquantes. Mesurez d'abord, dimensionnez ensuite.
Une aide à la décision, pas une recommandation d'architecture. L'outil raisonne sur ce que vous déclarez ; il ne voit ni votre locataire, ni vos profils de déploiement, ni vos restrictions d'inscription. Faites valider le résultat par un pilote avant de le transformer en plan de charge.
La stratégie
Autopilot : les scénarios possibles
Aucun de ces scénarios n'est meilleur dans l'absolu. Chacun répond à une population différente, et un parc réel en fait tourner deux ou trois en même temps — ce qui est précisément là où les ennuis commencent.
Deux axes de décision, et rien d'autre
Tout se joue au croisement de deux questions indépendantes. La première : comment l'appareil prouve qu'il appartient à l'entreprise — par son empreinte matérielle relevée avant le premier démarrage (V1), ou par rien du tout (V2), ce qui est à compenser. La seconde : où passe la phase de configuration — en atelier avant la livraison, ou entièrement devant l'utilisateur. Le pré-provisionnement est une option de V1 ; V2 est conçu pour un provisionnement piloté par l'utilisateur, sans étape atelier.
| Scénario | Identité appareil | Où passe le temps | Population cible |
|---|---|---|---|
| S1 — V1 + pré-provisioning | Empreinte matérielle (V1) | Atelier, puis 15-30 min chez l'utilisateur | Parc physique standard |
| S2 — V1 sans pré-provisioning | Empreinte matérielle (V1) | Entièrement chez l'utilisateur (2-4 h) | Volumes faibles, urgences |
| S3 — V2, piloté par l'utilisateur | Aucune — BYOD autorisé pour le groupe | Entièrement chez l'utilisateur, sans étape atelier | VM, population étroite et nommée |
| S4 — V2 + numéro de série | Numéro de série importé à la main | Entièrement chez l'utilisateur, import préalable | VM ou exceptions exigeant une preuve |
S1 — V1 + pré-provisioning (échange en atelier)
Le poste est entièrement préparé au banc avant d'être livré. C'est le seul scénario dont la durée de visite ne dépend presque pas du contenu du socle.
Avantages
- Visite utilisateur la plus courte — 15 à 30 minutes.
- Se parallélise en atelier, indépendamment de la disponibilité des utilisateurs.
- Compatible avec une jonction hybride si elle reste nécessaire.
- L'empreinte fournit la preuve d'appartenance sans configuration additionnelle.
Inconvénients
- Demande un flux logistique complet : réception, banc, stock, transport.
- Pré-provisionnement impossible sur un profil Shared — sans conséquence en mode auto-déployant.
- Le nombre de techniciens reste dimensionnant dès que le volume monte.
S2 — V1 sans pré-provisioning
Même profil, sans atelier : effacement et reconfiguration entièrement devant l'utilisateur.
Avantages
- Aucun flux logistique atelier à organiser.
- Garde la preuve d'appartenance par empreinte.
- Compatible avec des restrictions BYOD strictes.
Inconvénients
- Visite longue : 2 à 4 heures, et la personne est mobilisée du début à la fin.
- Un technicien sur un seul poste à la fois : aucune parallélisation.
- À volume, c'est cette ligne seule qui décide du calendrier.
S3 — V2, préparation pilotée par l'utilisateur
Stratégie V2 affectée à un groupe d'utilisateurs. Aucune étape atelier : l'appareil s'enregistre à l'ouverture de session.
Avantages
- Rien à pré-provisionner : adapté aux VM, qui changent d'empreinte à chaque recréation.
- Nommage automatique — préfixe et partie aléatoire.
Inconvénients
- Aucune preuve native d'appartenance : ces postes sont traités comme personnels par défaut.
- Les laisser passer demande d'autoriser le BYOD pour le groupe — un risque large pour une population étroite.
- Pas de jonction hybride possible.
- Impossible à pré-provisionner : la visite ne peut pas être raccourcie par l'atelier.
S4 — V2 + import du numéro de série
Une variante de S3 qui restaure la preuve d'appartenance sans repasser par l'empreinte V1.
Avantages
- Le blocage BYOD reste actif pour tout le monde : pas de brèche ouverte pour un groupe entier.
- Adapté à une population nommée et restreinte — VM identifiées, comptes de service.
Inconvénients
- Processus manuel à part entière : création, relevé du numéro de série, import, puis seulement l'enrôlement.
- Ajoute 10 à 20 minutes par machine, une fois, avant toute tentative d'inscription.
- Ne passe pas à l'échelle : demande un propriétaire nommé par machine.
Ce que chaque scénario coûte en techniciens
Illustration à 1 000 postes, 21 jours ouvrés par mois, 5 heures productives par technicien et par jour. Remplacez ces hypothèses par les vôtres dans l'outil ci-dessus : le rapport entre les lignes, lui, ne change pas.
| Durée de visite | Postes / jour / tech. | Jours-technicien | Techniciens pour 3 mois |
|---|---|---|---|
| 45 min (atelier, visée) | 6 | 167 | 3 |
| 75 min (atelier, constaté) | 4 | 250 | 4 |
| 2 h (sans atelier) | 2 | 500 | 8 |
| 4 h (sans atelier) | 1 | 1 000 | 16 |
ESP et restrictions : une seule s'applique, jamais deux
Quel que soit le scénario, les écrans d'état d'inscription et les restrictions d'inscription se résolvent PAR PRIORITÉ. Ajouter une nouvelle règle pour un scénario n'empêche pas les autres de continuer à s'appliquer si la priorité n'est pas revue — et plusieurs scénarios actifs en même temps, ce qui est le cas normal d'un parc réel, multiplient ce risque.
Le réflexe : vérifier le numéro de priorité de chaque ESP et de chaque restriction avant ET après toute modification, et documenter, pour chaque scénario actif, laquelle s'applique réellement à sa population.
Ce qui reste à valider avant de généraliser
- La liste d'exclusion du profil de déploiement — elle doit couvrir tous les autres projets — un poste qui correspond à deux profils est une situation à ne jamais créer.
- L'attestation TPM 2.0 des postes partagés — exigée par le mode auto-déployant, à tester sur le matériel réel avant d'en faire un plan de charge.
- Le recouvrement entre V1 et V2 — un utilisateur du groupe V2 qui reçoit un poste physique déjà enregistré : à trancher au pilote, pas à supposer.
- Le chiffrage définitif de la visite — il dépend du socle, du réseau et du contenu de l'ESP — à mesurer sur 20 à 30 postes avant de dimensionner l'équipe.