Remplissez cette page avant de planifier la première vague de déploiement. Rien dans le déploiement n’est difficile à obtenir. Ce qui bloque un déploiement, c’est de découvrir, le matin de la première vague, qu’une décision se trouve ailleurs dans l’organisation, ou que la personne qui peut approuver une entrée de flux sortant est absente. L’inventaire ci-dessous transforme cette découverte en un formulaire que quelqu’un remplit la semaine précédente.
Remplissez l’inventaire de préparation en une seule séance de travail, avec dans la salle toutes les personnes qui détiennent une réponse. La liste de contrôle transforme ensuite ces réponses en lignes regroupées par phase de travail. La dernière partie indique ce que coûte le déploiement en heures.
Chaque réponse change quelque chose en aval. Les réponses sur les agents décident quelles machines appartiennent à quelle vague. Les réponses sur les postes décident du canal d’installation. Les réponses réseau décident si la route est découverte ou fournie. Les réponses d’identité décident qui administre l’organisation. Quand la réponse est réellement « aucun », écrivez « aucun » plutôt que rien, pour qu’un lecteur ultérieur distingue une question répondue d’une question jamais posée.
| Élément | Pourquoi c’est important |
|---|
| Quels agents sont utilisés, et sur quelles machines | L’installation détecte les agents présents sur une machine et raccorde chacun d’eux. Connaître l’ensemble à l’avance indique quelles machines appartiennent à quelle vague. Dès qu’un agent remonte des données, la console affiche son niveau de contrôle |
| Si un agent tourne ailleurs que sur un poste personnel | Le client est installé une fois par machine qui exécute un agent, où que se trouve cette machine. Un hôte de build ou un poste partagé qui exécute un agent est concerné au même titre qu’un portable |
| Élément | Pourquoi c’est important |
|---|
| Répartition des systèmes d’exploitation et nombre de machines par système | Le client s’installe et s’exécute au niveau de l’utilisateur sur chaque plateforme prise en charge, sans droits d’administrateur. Les versions minimales sont macOS 13, Windows 10 1809 ou Windows Server 2019, Ubuntu 20.04 et Debian 10 |
| Architectures de processeur du parc | Des paquets existent pour macOS sur Apple silicon et Intel, Linux x64 et arm64, et Windows x64. Windows sur ARM64 et les distributions Linux basées sur musl, comme Alpine, ne sont pas pris en charge |
| Le canal de distribution ou de configuration que votre organisation exploite déjà | Les vagues 2 et 3 livrent l’installation par un canal qui atteint déjà ces machines. Ce canal transporte aussi l’identifiant de la vague depuis votre coffre de secrets |
| Si des machines d’une vague sont partagées par plusieurs personnes | L’installation et l’état local sont propres à chaque utilisateur. Chaque utilisateur d’une machine partagée fait sa propre installation |
| Élément | Pourquoi c’est important |
|---|
| Proxy sur le chemin : oui ou non | Décide si la route est découverte à l’installation ou lui est fournie. Voir Exigences réseau |
| Type de proxy : HTTP CONNECT, SOCKS5 ou configuration automatique de proxy | Les trois sont pris en charge. Un fichier de configuration automatique de proxy est évalué par le système d’exploitation sur Windows et macOS. Sur Linux, définissez la route explicitement |
| Authentification du proxy : aucune, Basic, Kerberos (Negotiate) ou NTLM | Aucune, Basic et Negotiate sont prises en charge. NTLM ne l’est pas, par choix de conception : un parc uniquement NTLM prévoit un chemin Negotiate ou non authentifié pour le client avant la première vague |
| Inspection TLS : oui ou non, et où se trouve l’autorité de certification d’interception | L’inspection ne demande aucune exception. La racine d’interception va dans le magasin de confiance du système d’exploitation, ou est fournie sous forme de fichier PEM à l’installation |
| Si les points d’accès de modèles que vos agents atteignent déjà restent joignables, et sont exemptés de la mise en mémoire tampon des réponses et de l’inspection des flux | Vos agents atteignent ces points d’accès exactement comme avant. Un équipement qui met en tampon une réponse en flux fait arriver la sortie de l’agent d’un seul bloc |
| Élément | Pourquoi c’est important |
|---|
| Le fournisseur d’identité SAML 2.0 de votre organisation | La console authentifie une organisation en SAML 2.0. Microsoft Entra ID, Okta, PingOne et Active Directory Federation Services se connectent ainsi. La connexion demande un administrateur de chaque côté |
| Domaines de messagerie autorisés | Les domaines autorisés et les invitations contrôlent ensemble qui peut rejoindre l’organisation |
| Annuaire pour la recherche des propriétaires : Microsoft Entra ID, Okta, Google Workspace, PingOne ou Active Directory | Une recherche en lecture seule rattache le propriétaire d’un agent à une personne. Elle ne crée ni ne supprime jamais d’utilisateurs. Cette connexion est facultative |
| Qui détient les rôles owner et admin dans la console | Les rôles de la console sont owner, admin, editor, viewer. Les personnes invitées commencent en viewer, et les réglages d’identité demandent admin |
| Élément | Pourquoi c’est important |
|---|
Où est conservée la OPENLATCH_API_KEY de chaque vague, et comment elle atteint une machine sans apparaître dans un script | Une clé par vague de déploiement, créée dans la console et révoquée quand la vague se termine. Les installations gérées la lisent depuis votre coffre de secrets comme variable d’environnement. Elle n’est jamais écrite dans un script, un paquet ou une ligne de commande |
| Élément | Pourquoi c’est important |
|---|
| Les dix machines de la vague 1 et leurs propriétaires | La vague 1 suit le parcours développeur. Des propriétaires nommés permettent de rapprocher chaque machine du registre des agents de la console |
| Comment vous joindrez OpenLatch pendant le déploiement | Convenez de la voie de support avant la première vague plutôt que pendant. Voir Exploiter |
Chaque ligne indique d’où vient la valeur et la page qu’elle bloque. Les quatre phases sont indépendantes : les lignes console et les lignes réseau avancent en parallèle la même semaine.
| # | Élément | D’où il vient | Bloque |
|---|
| 1 | Organisation créée dans la console | Votre contact OpenLatch crée l’organisation et invite son propriétaire. Acceptez l’invitation depuis l’adresse invitée. Les connexions suivantes commencent sur app.openlatch.ai par une étape e-mail dont la vérification dans le navigateur demande challenges.cloudflare.com | Configurer l’organisation |
| 2 | SAML connecté et testé | La console d’administration de votre fournisseur d’identité, pour l’identifiant d’entité, l’URL d’authentification, et le certificat ou l’URL de métadonnées. Saisis dans la console sous Settings › SAML SSO | Configurer l’organisation |
| 3 | Domaines de messagerie autorisés définis | Les mêmes réglages SAML que la ligne 2 | Configurer l’organisation |
| 4 | Rôles owner, admin, editor et viewer attribués | La console, sous Settings › Users. Les personnes invitées commencent en viewer | Configurer l’organisation |
| 5 | Annuaire choisi pour la recherche des propriétaires, facultatif | La console d’administration de votre annuaire. La recherche est en lecture seule | Configurer l’organisation |
| 6 | Conservation du journal d’audit définie | La console, sous Settings › Audit Trail : 90, 180, 365 ou 730 jours, ou une durée personnalisée, avec purge automatique et export | Configurer l’organisation |
| 7 | Canal de notification webhook ou Slack, facultatif | La console, sous Settings › Notification Channels | Configurer l’organisation |
| 8 | Identifiant de vague créé et stocké | La console, sous API Keys dans votre compte, depuis une session de navigateur connectée. Stocké dans le coffre de secrets de votre organisation | Configurer l’organisation |
| # | Élément | D’où il vient | Bloque |
|---|
| 9 | Entrée de flux sortant pour app.openlatch.ai sur TCP 443 approuvée | Votre processus de changement, d’après le tableau de Exigences réseau | Déployer le client |
| 10 | Les points d’accès de modèles que vos agents atteignent déjà restent joignables, et sont exemptés de la mise en tampon des réponses et de l’inspection des flux | La configuration de votre proxy ou de votre passerelle web sécurisée | Déployer le client |
| 11 | Type de proxy et chemin d’authentification confirmés | La configuration de votre proxy, lue au regard de la matrice de prise en charge | Déployer le client |
| 12 | Autorité de certification d’interception disponible en fichier PEM, si le système d’exploitation ne l’approuve pas déjà | L’export de votre propre autorité de certification | Déployer le client |
| # | Élément | D’où il vient | Bloque |
|---|
| 13 | Les agents à couvrir sont installés et connectés sur ces machines | Les machines elles-mêmes, confirmées avec la personne qui utilise chacune | Déployer le client |
| 14 | Installation revue pour la voie gérée | La voie gérée dans Déployer le client. Elle lit OPENLATCH_API_KEY depuis votre coffre de secrets et ne la porte jamais en clair | Déployer le client |
| # | Élément | D’où il vient | Bloque |
|---|
| 15 | Liste des machines de la vague 1 avec leurs propriétaires | Votre inventaire de postes, recoupé avec les propriétaires des agents | Vérifier et déployer |
| 16 | Développeurs informés que certains agents leur demandent de confirmer la connexion une fois | Votre propre communication de déploiement, envoyée avant le début de la vague | Vérifier et déployer |
| 17 | Voie de support convenue pour le déploiement | Exploiter | Vérifier et déployer |
| 18 | Responsable du retour arrière désigné | Votre propre décision : la personne qui peut suspendre une vague et retirer le client d’une machine | Vérifier et déployer |
Le déploiement du client se fait en trois vagues de deux semaines. La vague 1 installe environ dix machines par le parcours développeur. La vague 2 passe environ cinquante machines par le canal que vous exploitez déjà. La vague 3 s’étend au périmètre complet et se termine par la décision de passer en exploitation courante.
L’effort se concentre sur la première semaine, quand l’organisation est mise en place et la route prouvée sur une machine de chaque système d’exploitation du parc. Ensuite, chaque vague répète une procédure qui a déjà fonctionné.
| Phase de travail | Vague 1 | Vague 2 | Vague 3 | Effort habituel |
|---|
| Préparer la console | Connecter SAML, définir les domaines autorisés et la conservation de l’audit, inviter les personnes, créer l’identifiant de vague | Renouveler l’identifiant de vague | Transmettre la routine d’exploitation | Une journée la première semaine, puis quelques heures par semaine |
| Préparer le réseau | Approuver l’entrée de flux sortant et confirmer la route du proxy | Revoir la voie gérée | Aucun autre changement | Une demi-journée la première semaine |
| Préparer les machines | Prouver l’installation sur une machine par système d’exploitation, puis passer dix machines par le parcours développeur | Porter l’installation dans le canal que vous exploitez déjà et lancer la vague | Étendre le même canal aux machines restantes | Quelques minutes par machine après la première |
| Confirmer et exploiter | Confirmer que chaque machine installée apparaît dans le registre des agents avec un propriétaire | Point hebdomadaire et revue de la voie gérée | Point hebdomadaire, puis décision de passer en exploitation courante | Un point hebdomadaire pendant tout le déploiement |
- Remplissez l’inventaire de préparation en une seule séance avant de planifier la première vague. Chaque case vide est une décision que quelqu’un prendra plus tard sous pression.
- Une seule entrée de flux sortant est obligatoire :
app.openlatch.ai sur TCP 443, en sortie. Tout le reste sur le chemin est le trafic propre de vos agents, qui ne change pas.
- Un parc dont le proxy est uniquement NTLM bloque le déploiement. Prévoyez un chemin Negotiate ou non authentifié pour le client.
- Aucun droit d’administrateur n’est nécessaire sur une machine. L’installation et l’état local sont propres à chaque utilisateur : une machine partagée par plusieurs personnes demande une installation par utilisateur.
- Une
OPENLATCH_API_KEY par vague de déploiement, conservée dans votre coffre de secrets et révoquée dans la console quand la vague se termine. Elle n’apparaît jamais dans un script, un paquet ou une ligne de commande.
