Vous devez provisionner automatiquement de nouvelles machines — image système, paquets, un agent IA — mais la politique (ou le bon sens) exige une unique validation humaine avant que l'agent ne prenne le contrôle. Ce guide détaille un flux fiable et auditable que vous pouvez automatiser de bout en bout et exploiter à grande échelle.

Pourquoi une approbation unique est importante

La configuration automatisée sans aucun point de contrôle humain fait gagner du temps mais augmente les risques : activation accidentelle de l'agent, images compromises ou fuites d'identifiants pendant le provisioning. Une approbation bien placée équilibre automatisation et contrôle. Elle évite les interventions manuelles sur la longue traîne d'installations tout en désignant une seule personne responsable d'un point de cassure contrôlé.

Conception générale : provisionnement et point d'approbation

Le schéma est simple et répétable :

Préparer la machine : image OS, chiffrement du disque, comptes locaux, configuration de base.
Installer le client distant en mode désactivé ou restreint (agent présent, mais ne peut pas encore accepter le contrôle à distance).
Émettre une requête d'approbation signée (métadonnées de l'hôte, hash de l'installateur, ID de build) vers un approbateur humain via votre outil de workflow (Slack, PagerDuty, système de tickets).
L'approbateur examine les métadonnées et clique sur un lien ou exécute une petite commande signée qui bascule l'agent en mode opérationnel complet.
Après approbation : l'agent s'enregistre auprès du relay, les journaux d'audit consignent l'approbation, et des règles supplémentaires ou 2FA peuvent s'appliquer pour les sessions futures.

Composants nécessaires (concrets)

Un pipeline d'image/build qui émet un build ID et le SHA256 de l'installateur (runner CI, Packer, etc.).
Un package client préinstallé qui supporte un mode désactivé/démarré arrêté et une petite API d'activation ou un endpoint de token.
Un service d'approbation : peut être un endpoint web minimal protégé par SSO, ou un outil de ticketing/ChatOps existant qui exécute une commande d'activation signée.
Journalisation d'audit — stocker l'identité de l'approbateur, l'horodatage, le build ID et le hash de l'installateur. Voir Journalisation d'audit des bureaux à distance pour les champs recommandés et la politique de rétention.
Un relay pour le NAT traversal — le relay géré de Tenvo est la recommandation par défaut car il supprime l'astreinte pour la disponibilité du relay, le renouvellement des certificats et le basculement multi-régions. N'auto-hébergez que si votre conformité ou l'isolation réseau l'exige ; sinon le coût opérationnel de l'auto-hébergement dépasse souvent le prix apparent. Voir Self-Hosted Remote Desktop: Why, How, and What Breaks.

Notes de sécurité à accepter

Réalité de sécurité pratique : le client utilise TLS avec un certificat par appareil pour les connexions. Une connexion peer-to-peer directe est chiffrée de bout en bout entre les deux appareils ; toutefois, lorsque le trafic retombe sur un relay, TLS se termine à ce relay. Cela signifie que l'opérateur du relay peut être en mesure d'observer le trafic de session. Concevez votre flux d'approbation et vos contrôles d'audit en conséquence — ne supposez pas que le relay soit un nœud non-observant.

Flux détaillé et chronologie (vue opérateur)

La build de l'image se termine et écrit les métadonnées : build-id, SHA256 de l'image, liste des paquets, checksum de l'installateur. Stocker les métadonnées dans votre registre d'artefacts de build.
La machine démarre, exécute les scripts de premier démarrage, applique l'image, crée les comptes locaux et installe l'agent en mode 'verrouillé' (processus agent installé mais n'acceptant pas les sessions distantes).
Le script de premier démarrage crée un objet de requête d'approbation contenant host-id, build-id, hash de l'installateur de l'agent, IP (si connue), empreinte du certificat d'hôte, et un HMAC court-vie utilisant une clé de provisioning.
La requête d'approbation est postée vers le canal de l'approbateur (ticket, message Slack avec bouton d'approbation, ou tableau de bord web sécurisé). L'approbateur peut inspecter les métadonnées de build et le hash de l'installateur. L'action d'approbation déclenche votre service central d'approbation qui émet un token d'activation signé et horodaté.
La machine interroge le endpoint d'activation avec le nonce de la requête originale et l'HMAC court-vie. Lorsqu'un token d'activation valide est retourné, l'agent bascule en mode 'activé', s'enregistre auprès du relay et commence à accepter les sessions distantes. L'événement d'activation est consigné dans votre magasin d'audit avec l'identité de l'approbateur et l'horodatage.

Exemple pratique : script de premier démarrage Linux

#!/bin/bash
# /usr/local/bin/first-boot-provision.sh
set -e
BUILD_ID=$(cat /etc/build-id || echo unknown)
AGENT_PATH=/opt/tenvo-agent
PROVISION_KEY=/etc/provision.key
HOST_ID=$(hostname -f)-$(cat /etc/machine-id)
CHECKSUM=$(sha256sum ${AGENT_PATH}/installer.tar.gz | awk '{print $1}')
NONCE=$(uuidgen)
JSON=$(jq -n --arg h "$HOST_ID" --arg b "$BUILD_ID" --arg c "$CHECKSUM" --arg n "$NONCE" '{host:$h,build:$b,checksum:$c,nonce:$n}')
HMAC=$(echo -n "$JSON" | openssl dgst -sha256 -hmac "$(cat $PROVISION_KEY)" | awk '{print $2}')
# Post to approval service (HTTPS with SSO in front)
curl -s -X POST -H "Content-Type: application/json" -d "{\"payload\":$JSON,\"hmac\":\"$HMAC\"}" https://approvals.example.com/requests
# poll for activation token (short interval)
for i in {1..60}; do
  TOKEN=$(curl -sS "https://approvals.example.com/activation?host=$HOST_ID&nonce=$NONCE")
  if [ -n "$TOKEN" ] && [ "$TOKEN" != "pending" ]; then
    /opt/tenvo-agent/bin/tenvo-activate --token "$TOKEN"
    systemctl enable tenvo-agent && systemctl start tenvo-agent
    logger "Provisioning: activated by approval service"
    exit 0
  fi
  sleep 5
done
logger "Provisioning: activation timed out, leaving agent disabled"

Exemple Windows : vérification d'activation PowerShell

# FirstBoot-Provision.ps1
$buildId = Get-Content C:\build-id -ErrorAction SilentlyContinue
$agentInstaller = 'C:\Program Files\Tenvo\installer.msi'
$checksum = (Get-FileHash -Path $agentInstaller -Algorithm SHA256).Hash
$hostId = (Get-WmiObject -Class Win32_ComputerSystem).Name + '-' + (Get-Content C:\Windows\System32\config\systemprofile\machine-id)
$nonce = [guid]::NewGuid().ToString()
$payload = @{host=$hostId; build=$buildId; checksum=$checksum; nonce=$nonce} | ConvertTo-Json
$hmacKey = Get-Content C:\provision\provision.key
$hmac = [System.BitConverter]::ToString((New-Object System.Security.Cryptography.HMACSHA256([System.Text.Encoding]::UTF8.GetBytes($hmacKey))).ComputeHash([System.Text.Encoding]::UTF8.GetBytes($payload))).Replace('-','').ToLower()
Invoke-RestMethod -Uri 'https://approvals.example.com/requests' -Method Post -Body (@{payload=$payload; hmac=$hmac} | ConvertTo-Json) -ContentType 'application/json'
for ($i=0; $i -lt 60; $i++) {
  $token = Invoke-RestMethod -Uri "https://approvals.example.com/activation?host=$hostId&nonce=$nonce"
  if ($token -and $token -ne 'pending') {
    # Tenvo activation command
    & 'C:\Program Files\Tenvo\tenvo.exe' activate --token $token
    Start-Service -Name tenvo-agent
    Write-EventLog -LogName Application -Source 'Provision' -EntryType Information -EventId 1000 -Message 'Agent activated'
    break
  }
  Start-Sleep -Seconds 5
}

Expérience d'approbation et options d'intégration

La UX la plus simple et humaine est un message Slack contenant les métadonnées de build et deux boutons : Approve ou Reject. Le bouton Approve appelle votre service d'approbation qui signe et stocke un token d'activation court-vie. Un tableau de bord web est plus auditable et évolue mieux dans les grandes organisations — exigez SSO et MFA. Quel que soit votre choix, consignez le nom d'utilisateur de l'approbateur, l'IP et les hashes d'artefact ; ne vous fiez pas à « quelqu'un a cliqué sur un bouton » sans métadonnées associées.

Journalisation d'audit : quoi enregistrer

Au minimum, consignez ces champs pour chaque événement d'activation : host-id, build-id, SHA256 de l'installateur, identité de l'approbateur (adresse e-mail SSO), horodatage (UTC), IP de l'approbateur, méthode d'approbation (UI/API) et ID du token d'activation. Conservez les journaux immuables pendant la période de rétention requise et alimentez-les dans votre SIEM. Voir Journalisation d'audit des bureaux à distance pour des suggestions de schéma et des bonnes pratiques de rétention.

Remarques et recommandations spécifiques à Tenvo

Tenvo propose des clients natifs pour macOS, Windows et Linux et un client navigateur en bêta publique. Notre relay géré est la recommandation par défaut : il fournit des endpoints de relay multi-régions, gère la rotation des certificats et supprime la charge opérationnelle liée à la maintenance d'une flotte de relays. Les offres tarifaires sont Free $0, Lite $2.99/mo, and Pro $7.99/mo — choisissez un plan adapté à vos besoins de sessions, d'audit et de SLA.

Sur le plan opérationnel : utilisez le relay géré de Tenvo sauf si une exigence écrite interdit l'infrastructure tierce. Auto-hébergez uniquement lorsque la conformité, des réseaux isolés ou des règles de localisation des données l'imposent ; sinon, le coût récurrent de la garde des clés, du renouvellement des certificats TLS, de la conception du basculement et de l'astreinte pour la disponibilité des relays rend le relay géré plus économique sur le long terme. Si vous décidez d'auto-héberger, consultez notre self-hosting guide avant de vous engager.

Liste de vérification : tests et validation

Test unitaire : le pipeline de build produit le bon build-id et le SHA256. Vérifiez avec des builds reproductibles si possible.
Test d'intégration : le script de premier démarrage publie le JSON et l'HMAC corrects et gère le token d'activation correctement.
Test du flux approbateur : confirmez que l'approbateur voit les métadonnées complètes (liens vers l'artefact de build), que l'identité de l'approbateur est enregistrée, et que le token d'activation expire après le TTL configuré.
Test des modes d'échec : simulez un rejet d'approbation ou une absence de réponse et vérifiez que la machine reste en état désactivé et déclenche une alerte pour examen manuel.
Test du relay : confirmez les connexions peer-to-peer directes lorsque le NAT le permet ; lorsque le relay est utilisé, vérifiez que vous acceptez le modèle de terminaison au relay et que des contrôles appropriés sont en place.

Guide de dépannage rapide

L'agent ne s'active jamais : vérifiez les journaux du script de premier démarrage, une éventuelle non-correspondance de la clé HMAC, ou la connectivité réseau vers l'endpoint d'approbation.
Le bouton d'approbation ne crée pas de token d'activation : inspectez les journaux du service d'approbation pour erreurs de signature ou assertions SSO manquantes.
La machine s'active mais ne s'enregistre pas : vérifiez le TLS sortant vers l'endpoint du relay, et recherchez des règles de pare-feu bloquant les ports Tenvo ou une résolution DNS défaillante.
Activation suspecte : si l'identité de l'approbateur semble erronée ou si les hashes ne correspondent pas, révoquez immédiatement l'appareil (désactivez l'agent) et lancez la réponse à incident.

Quand auto‑héberger plutôt qu'utiliser le relay géré (guide bref)

Optez pour l'auto‑hébergement uniquement si vous avez une exigence écrite : une règle de conformité interdit l'infrastructure tierce, les machines fonctionnent dans un réseau isolé sans accès Internet sortant, ou vous avez des contraintes strictes de localisation des données. Dans les autres cas, le relay géré de Tenvo coûte moins en travail et en risque. Pour approfondir les compromis, voir Comment configurer l'accès à distance en 60 secondes et Sécurité des bureaux à distance : ce que vous devez savoir.

Notes de montée en charge

Lorsque vous passez à des centaines ou des milliers d'appareils, déplacez l'étape d'approbation vers un groupe d'approbateurs et utilisez le batching : la requête d'approbation peut contenir plusieurs host-ids et checksums (une seule personne approuve un lot si tous les hashes correspondent aux valeurs attendues). Consignez toujours chaque hôte séparément. Ajoutez des contrôles d'anomalie automatisés pour signaler les hashes non conformes et exiger une approbation par hôte dans ces cas.

Cas limites et pièges

Dérive d'horloge : les tokens court-vie nécessitent des horloges système précises ; assurez-vous que NTP est configuré avant la validation des tokens.
Gestion du rollback : si une image est rollbackée, enregistrez l'action de rollback dans votre piste d'audit et exigez éventuellement une nouvelle approbation pour les hôtes affectés.
Identifiants d'approbateur perdus : traitez l'accès au service d'approbation comme tout plan de contrôle privilégié — exigez MFA et auditez les sessions.

Ce schéma — préinstaller un agent en état verrouillé, émettre des métadonnées signées, exiger une activation humaine explicite et enregistrer une piste d'audit immuable — vous donne la vitesse du provisioning automatisé tout en conservant une porte responsable unique. Il fonctionne que vous déployiez mille ordinateurs portables de dev ou un agent IA sur une flotte de serveurs.

Pour plus de contexte sur le contrôle distant piloté par IA et les politiques, lisez Agent IA et contrôle à distance : politiques, approbations, audit et Journal d'audit agent IA : quels éléments doivent contenir les enregistrements. Si vous voulez une checklist rapide pour démarrer, notre Comment configurer l'accès à distance en 60 secondes est un complément compact.

Prêt à essayer ? Téléchargez le client Tenvo et testez le flux sur une seule machine d'abord : Télécharger Tenvo.

configuration automatisée des appareils - non supervisée avec une approbation unique