Déployez une passerelle VPN OPNsense

Azure VPN Gateway est un service plébiscité pour sa sécurité, sa redondance et la simplicité de son intégration native dans Microsoft Azure. Cependant, pour des projets de plus petite envergure ou lorsque vous disposez déjà de compétences réseau et d’infrastructures maîtrisées, il peut être judicieux d’explorer des solutions open source ou des distributions spécialisées. C’est dans cette optique que nous verrons comment déployer un VPN OPNsense sur Azure.

Comment fonctionne un tunnel IPsec ?

Les tunnels IPsec se mettent en place en deux grandes étapes :

Phase 1 – IKE (Internet Key Exchange)

  • Les deux extrémités (pair A et pair B) négocient d’abord une association de sécurité IKE SA.
  • Elles s’authentifient mutuellement (certificat, clé pré-partagée, etc.) et conviennent des paramètres de chiffrement (algorithme, mode DH, durée de vie des clés).
  • À l’issue, un canal chiffré et authentifié est établi pour protéger les échanges de la phase 2.

Phase 2 – IPsec SA

  • Dans ce canal sécurisé, les pairs négocient plusieurs Security Associations secondaires (appelées Child SA), qui définiront le chiffrement et l’intégrité du trafic utilisateur.
  • Elles conviennent des sous-réseaux à protéger, des ports et protocoles autorisés, puis génèrent les clés de session IPsec.
  • Une fois la Child SA montée, le tunnel est opérationnel : tout paquet envoyé vers le sous-réseau distant est chiffré et encapsulé dans IPsec.

Qu’est-ce qu’une passerelle VPN Azure ?

Une passerelle VPN Azure (Azure VPN Gateway) agit comme un point de terminaison chiffré permettant d’établir des tunnels IPsec/IKE entre votre réseau on-premises (ou vos clients VPN individuels) et vos réseaux virtuels Azure.

Elle prend en charge plusieurs scénarios :

  • Site-à-Site (connexion permanente entre votre datacenter et Azure)
  • Point-à-Site (accès distant des utilisateurs)
  • VNet-à-VNet (liaison sécurisée entre réseaux virtuels)

Quels sont les SKUs disponibles pour les passerelles VPN Azure ?

Les passerelles VPN Azure se déclinent en versions classiques et zone-redondantes :

GénérationSKUTunnels S2S/VNet-to-VNetConnexions P2S (IKEv2/OpenVPN)Débit agrégé BGP supportéZone-redondant
Gen 1BasicMax. 10Non supporté100 MbpsNonNon
VpnGw1Max. 30Max. 250650 MbpsOuiNon
VpnGw2Max. 30Max. 5001 GbpsOuiNon
VpnGw3Max. 30Max. 10001,25 GbpsOuiNon
VpnGw1AZMax. 30Max. 250650 MbpsOuiOui
VpnGw2AZMax. 30Max. 5001 GbpsOuiOui
VpnGw3AZMax. 30Max. 10001,25 GbpsOuiOui
Gen 2VpnGw2Max. 30Max. 5001,25 GbpsOuiNon
VpnGw3Max. 30Max. 10002,5 GbpsOuiNon
VpnGw4Max. 100*Max. 50005 GbpsOuiNon
VpnGw5Max. 100*Max. 1000010 GbpsOuiNon
VpnGw2AZMax. 30Max. 5001,25 GbpsOuiOui
VpnGw3AZMax. 30Max. 10002,5 GbpsOuiOui
VpnGw4AZMax. 100*Max. 50005 GbpsOuiOui
VpnGw5AZMax. 100*Max. 1000010 GbpsOuiOui

Combien coûte les passerelles VPN Azure ?

Le prix de la passerelle VPN dépend du SKU choisi. Voici quelques tarifs :

SKUPrix mensuel estimé (€)
Basic22,95 €
VpnGw1121,11 €
VpnGw2312,33 €
VpnGw3796,77 €
VpnGw41 338,57 €
VpnGw52 326,56 €

Attention : ces prix correspondent uniquement au coût de compute de la passerelle (744 heures d’utilisation par mois) et n’incluent pas les frais de transfert de données sortantes.

L’ancien VPN de type basique présentait un tarif particulièrement attractif :

Le service le moins cher est maintenant le SKU VpnGw1, mais le prix est plus élevé :

En comparaison, le service OPNsense déployé via une VM affiche un coût un plus faible :

Voici également le tarif appliqué pour le VPN OPNsense pour un engagement d’un an sur la machine virtuelle :

Qu’est-ce que la passerelle VPN OPNsense sur Azure ?

OPNsense VPN est la solution de création de tunnels sécurisés intégrée à OPNsense, un pare-feu/routeur open-source basé sur FreeBSD. Elle prend en charge plusieurs protocoles majeurs :

  • IPsec : idéal pour les liaisons site-à-site ou les connexions distantes, avec négociation IKEv1/IKEv2, clés pré-partagées ou certificats, et prise en charge de BGP pour le routage dynamique.
  • OpenVPN : pour les accès distants sur TCP ou UDP, avec authentification par utilisateur, certificats ou serveur RADIUS, et options de chiffrement AES-GCM.
  • WireGuard : un protocole moderne, léger et performant, offrant des temps de mise en place réduits et une empreinte cryptographique simplifiée.

Peut-on déployer la passerelle VPN OPNsense sur Azure ?

Oui, il est tout à fait possible de déployer OPNsense dans Azure en tant que machine virtuelle. Afin de voir si cela marche vraiment, voici les différentes étapes que nous allons suivre sur un environnement de test :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Pour tester mon environnement, j’ai également provisionné les deux machines virtuelles suivantes pour simuler des ressources opposées :

J’y ai également mis en place une passerelle Bastion :

Enfin, j’ai également déployé une passerelle VPN Azure pour tester le tunnel :

Commençons par créer une nouvelle machine virtuelle Azure contenant la passerelle VPN OPNsense.

Etape I – Préparation de la machine virtuelle OPNsense :

Pour cela, cliquez sur le lien GitHub suivant pour déployer le template ARM sur votre environnement Azure : https://github.com/dmauser/opnazure

Sélectionnez ensuite le scénario OPNsense souhaité et renseignez les informations de base, puis cliquez sur Suivant :

Conservez ou ajustez la taille de la VM, puis validez en cliquant Suivant :

Constatez la présence de deux sous-réseaux, Trusted et Untrusted, puis lancez la validation Azure :

Une fois la validation réussie, le déploiement des ressources démarre automatiquement :

Patientez quelques minutes, puis cliquez ici pour accéder aux ressources créées :

Copiez les adresses IP privées et publiques de la VM OPNsense :

Modifiez la règle de pare-feu pour autoriser l’accès HTTPS à la VM :

Vérifiez la présence du sous-réseau Trusted, puis copiez son plan d’adressage :

Connectons-nous maintenant à notre console d’administration OPNsense pour avancer sur la configuration de notre tunnel.

Etape II – Configuration d’OPNsense :

Ouvrez votre navigateur, collez-y l’IP publique de la VM OPNsense, renseignez les identifiants ci-dessous, puis cliquez sur Login :

  • Login : root
  • Mot de passe : opnsense

Changez immédiatement le mot de passe pour des raisons de sécurité :

Commencez par créer une clé partagée destinée au handshake IPsec :

Dans la section VPN IPsec, cliquez-ici pour créer une nouvelle connexion et choisissez vos propositions de chiffrement :

Renseignez les champs requis : l’IP locale de la VM OPNsense et l’adresse IP publique de la passerelle VPN Azure :

Ajoutez une authentification locale en réutilisant la clé partagée, puis enregistrez :

Répétez l’opération pour l’authentification distante, puis sauvegardez :

Éditez ensuite la section Child en renseignant les plans d’adressage respectifs, puis cliquez sur Enregistrer :

Cliquez sur Sauvegarder :

Enfin, cliquez sur Appliquer pour finaliser la configuration IPsec :

Dans la section pare-feu, constatez la règle sortante déjà préconfigurée :

Créez une nouvelle règle entrante pour autoriser l’accès depuis la passerelle VPN Azure :

Activez cette nouvelle règle pare-feu :

Sur le pare-feu OPNsense, ajoutez les règles nécessaires pour établir la liaison IPsec dans la section WAN :

La configuration OPNsense est maintenant terminée. La prochaine étape consiste à configurer la passerelle VPN Azure pour se connecter à la première.

Etape III – Configuration de la passerelle VPN Azure :

Copiez l’adresse IP publique de la passerelle VPN Azure :

Dans le Network Security Group de votre VM OPNsense, créez une règle pour autoriser l’IP de la passerelle VPN Azure :

Créez une Local Network Gateway en renseignant l’IP publique de votre passerelle VPN OPNsense et le plan d’adressage du sous-réseau Trusted :

Établissez ensuite la connexion VPN Azure pour finaliser l’interconnexion entre les deux passerelles :

Collez la clé d’authentification, puis enregistrez la configuration de la connexion :

Associez également une table de routage au sous-réseau Trusted, en y incluant le préfixe 0.0.0.0/0 afin de diriger tout le trafic via la VM OPNsense :

Tout est maintenant en place pour le test de connectivité entre nos deux machines virtuelles.

Etape IV – Test de la connexion VPN :

Retournez dans le menu des connexions IPsec OPNsense, puis cliquez ici pour démarrer la connexion IPsec côté OPNsense :

Attendez quelques secondes jusqu’à l’apparition de la Phase 2 de la connexion IPsec :

Une fois la Phase 2 affichée, cliquez ici pour visualiser le journal contenant les événements IPsec :

Constatez l’apparition des différents états de la connexion entre les deux passerelles VPN :

Vérifiez l’apparition de Security Associations dans la base de données IPsec :

Vérifiez l’apparition de Security Policies dans la base de données IPsec :

Retournez sur le portail Azure et observez le changement de statut de la connexion VPN Azure :

Démarrez les deux machines virtuelles de test pour valider la liaison :

Sur les deux VM de test, désactivez temporairement la règle de pare-feu ICMP suivante pour autoriser le ping :

Effectuez des tests de ping réciproques entre les deux machines virtuelles :

Interrompez la connexion depuis OPNsense :

Constatez la disparition de la Phase 2 dans la console OPNsense :

Vérifiez également l’échec du ping entre les deux VM :

Relancez la connexion IPsec depuis OPNsense et observez la réapparition de la Phase 2 :

Confirmez la reprise du ping sur les deux machines virtuelles de test :

Conclusion

Si Azure VPN Gateway reste la solution de référence pour une interconnexion cloud sécurisée et redondante, l’utilisation d’une VM OPNsense sur Azure offre une alternative open source particulièrement adaptée aux petits projets ou aux environnements où vous souhaitez tirer parti de vos compétences réseau existantes.

Vous gagnez en flexibilité de configuration, en contrôle détaillé des politiques VPN et en possibilité d’étendre facilement vers d’autres protocoles (OpenVPN, WireGuard).

Cette approche hybride combine la robustesse du cloud Azure et la puissance d’OPNsense pour bâtir un VPN sur mesure parfaitement aligné avec vos besoins.

Migrez un vieux PC de 10 à 11 !

Windows 10 verra son support étendu s’achever le 14 octobre 2025, poussant beaucoup à envisager Windows 11. Comment vérifier la compatibilité de votre poste et quelles sont les solutions officielles ou détournées pour migrer même si votre matériel ne remplit pas tous les critères ? C’est ce que nous allons voir ensemble dans cet article consacré à la migration d’un poste, pleinement fonctionnel, mais qui ne satisfait pas toutes les conditions.

Il est parfois frustrant de constater l’« air du tout jetable » qui règne dans le monde de l’informatique : des machines parfaitement fonctionnelles se retrouvent considérées comme obsolètes dès qu’un détail matériel (TPM, Secure Boot ou CPU non listé) n’est pas validé.

Pourtant, nombre de ces postes ont encore de belles années devant eux et peuvent très bien faire le boulot sous Windows 11, si l’on savait simplement contourner ce petit verrou.

C’est d’ailleurs grâce à un message de Marjorie SIEGLER sur LinkedIn que j’ai découvert la méthode la plus simple pour faire sauter ce contrôle et donner une seconde vie à ces PC « délaissés ». Un grand merci à elle pour ce partage éclairé !

Quand Microsoft arrêtera-t-il le support de Windows 10 ?

Le support grand public (« Mainstream Support ») de Windows 10 a pris fin le 13 octobre 2020. Microsoft assure toutefois un support étendu (« Extended Support ») jusqu’au 14 octobre 2025, date à laquelle toutes les mises à jour de sécurité et correctifs pour Windows 10 cesseront d’être publiés.

Qu’est-ce que Windows 11 ?

Windows 11 est la version suivante de Windows après Windows 10. Publié officiellement par Microsoft en octobre 2021, il apporte un certain nombre de changements tant au niveau de l’interface utilisateur que des fonctionnalités sous-jacentes par rapport à Windows 10.

Quels sont les prérequis pour passer de Windows 10 à Windows 11 ?

Voici les conditions minimales à respecter pour passer de Windows 10 à Windows 11. Ces prérequis sont inchangés depuis leur publication initiale et doivent tous être satisfaits simultanément pour que l’upgrade in-place soit autorisée :

CatégoriePrérequis minimaux
Processeur (CPU)Processeur 64 bits cadencé à ≥ 1 GHz avec au moins 2 cœurs, figurant dans la liste officielle des CPU compatibles Windows 11 et prenant en charge les instructions SSE 4.1/4.2, AVX.
Mémoire vive (RAM)4 Go ou plus.
StockageDisque (physique ou partition) d’au moins 64 Go d’espace disponible pour l’installation.
Firmware systèmeDémarrage en mode UEFI avec Secure Boot activé.
TPM (Trusted Platform Module)Module TPM version 2.0 activé.
Carte graphiqueCompatible DirectX 12 ou version ultérieure avec pilote WDDM 2.0.
ÉcranÉcran HD (720p) de plus de 9″ en diagonale, 8 bits par canal de couleur.
Connexion Internet et comptePour Windows 11 Home, un compte Microsoft et une connexion Internet sont nécessaires pour la configuration initiale.

Peut-on vérifier la compatibilité de son poste pour passer à Windows 11 ?

Microsoft propose une application gratuite, PC Health Check, qui analyse automatiquement votre machine et vous indique si elle remplit les conditions minimales pour Windows 11 :

Quid des extended security updates (ESU) pour Windows 10 ?

Les Extended Security Updates (ESU) pour Windows 10 sont un programme payant permettant aux utilisateurs de continuer à recevoir uniquement les correctifs de sécurité (critique et important) après la date de fin de support officielle de Windows 10 (14 octobre 2025).

Le support standard de Windows 10 s’achève le 14 octobre 2025. Les ESU Windows 10 débutent alors, et s’étendent jusqu’au 14 octobre 2028 (trois années au total).

Pour les acheter, vous pourrez passer via le Volume Licensing (Microsoft 365, Microsoft 365 FPP, etc.) ou auprès d’un partenaire Microsoft avec un contrat EA unqiuement (pour l’instant).

Pour information, vous aurez la possibilité d’enrôlement gratuit pour les ESU quand les machines Windows 10 sont hébergées sur :

  • Azure Virtual Desktop
  • Azure VM
  • Windows 365

Voici d’ailleurs un tableau Microsoft montrant les autres ESU actuellement en vigueur :

Peut-on malgré tout migrer sur Windows 11 sans valider tous les prérequis ?

Il n’existe pas de voie « officielle » pour forcer l’installation de Windows 11 sur un matériel qui ne respecte pas tous les prérequis. Microsoft bloque volontairement l’upgrade in-place (et parfois même la clean install) dès qu’un des critères essentiels (TPM 2.0, Secure Boot, CPU compatible, etc.) n’est pas rempli.

Cependant, plusieurs utilisateurs avancés ont découvert des contournements (workarounds) pour installer Windows 11 sur du matériel non pris en charge. Voici les principales méthodes, ainsi que leurs risques et limitations.

  • Méthode 1 : modification du registre avant l’upgrade in-place :
  • Méthode 2 : clean install depuis un ISO modifié (offline) :
  • Méthode 3 : utilisation d’un script tiers (par exemple Flyby11) :

Méthode 4 : utilisation d’un argument d’installation :

Afin de voir si cela marche vraiment, voici les différentes étapes que nous allons suivre afin de tester la méthode 4 sur un environnement de test :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de mise à jour d’un poste Windows 10 non compatible vers Windows 11, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

N’ayant pas d’anciens postes physiques à disposition (à part celui de mon fils 🤣), j’ai choisi de le simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure.

Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle présent dans la famille Dsv3, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la ou les futures machines virtuelles invitées, puis cliquez ensuite sur Suivant :

Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle hôte (Hyper-V) :

Ensuite, cliquez-ici pour déployer le service Azure Bastion :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :

Peu après, constatez le déploiement réussi d’Azure Bastion, puis renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :

Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les deux rôles suivants :

  • Rôle DHCP
  • Rôle Hyper-V
Install-WindowsFeature -Name DHCP,Hyper-V –IncludeManagementTools

Attendez environ une minute que l’installation des 2 rôles se termine :

Lancez la commande suivante pour lancer un redémarrage immédiat de votre VM hôte (Hyper-V) :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour vous reconnecter à celle-ci, toujours via le service Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel dans Hyper-V de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, couplé au serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :

Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :

Créez un nouveau volume NTFS :

L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.

Etape II – Création de la machine virtuelle Windows 10 :

Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle invitée, puis d’y installer l’OS. Pour ma part, je suis passé par mon abonnement Visual Studio :

Attendez la fin du téléchargement pour continuer :

Depuis votre VM hôte (Hyper-V), ouvrez votre console Hyper-V Manager :

Cliquez-ici pour créer votre machine virtuelle invitée :

Modifiez les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :

Choisissez Génération 1 :

Modifiez la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

Cliquez sur Suivant :

Utilisez le fichier ISO téléchargé précédemment, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 10 :

Une fois la machine virtuelle Windows 10 créée, modifiez sa configuration comme ceci :

Double-cliquez sur votre machine virtuelle, puis cliquez-ici pour lancer le démarrage de la VM :

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

Lancez l’installation de Windows :

Une fois Windows 10 correctement installé, installez PC Health Check afin de constater l’impossibilité en l’état actuel de basculer sur Windows 11 :

Nous allons maintenant pouvoir tester la méthode alternative pour installer malgré tout Windows 11 sur cette machine virtuelle

Etape III – Mise à jour vers Windows 11

Avant de mettre à jour vers Windows 11, commencez par ouvrir Windows Update afin de mettre à jour tous les patchs existants :

Une fois tous les patchs installés, vérifiez à nouveau Windows Update :

Téléchargez cette fois l’image ISO de Windows 11 :

Une fois téléchargée, extrayez le contenu de l’ISO dans un dossier :

Puis créez un fichier texte avec le contenu suivant :

setup.exe /product server

Sauvegardez ce fichier texte avec une terminaison BAT :

Ouvrez en mode administrateur l’exécuteur de commande Windows, puis lancez l’application setup.bat :

Autorisez l’action en cliquant sur Oui :

Attendez plusieurs minutes que l’installation se prépare :

Cliquez sur Suivant :

Attendez la vérification de mises à jour Windows :

Attendez encore quelques minutes :

Acceptez les termes et conditions de Microsoft Windows :

Cliquez-ici pour conserver les informations en place sur votre poste :

Attendez quelques minutes :

Attendez la seconde vérification des mises à jour Windows :

Cliquez-ici pour démarrer l’installation de Windows 11 :

Attendez plusieurs minutes que l’installation se termine :

Attendez encore plusieurs redémarrages de votre poste :

Authentifiez-vous avec votre compte sur Windows 11 :

Retournez dans les paramètres Windows afin de vérifier le bon changement de version de votre OS :

Retournez à nouveau dans Windows Update pour vérifier, puis lancez les nouvelles mises à jour disponibles :

Conclusion

En définitive, si vous êtes dans la situation où votre poste Windows 10 parfaitement fonctionnel ne remplit pas tous les critères officiels de Windows 11, sachez qu’il existe plusieurs moyens de contourner ces contrôles et d’offrir une seconde vie à votre machine.

Gardez toutefois à l’esprit que ces contournements ne sont pas supportés officiellement par Microsoft : vous prenez le risque de ne plus recevoir certaines mises à jour futures, voire de rencontrer des limitations sur les fonctionnalités de sécurité (Windows Hello, BitLocker, etc.)

En revanche, si votre objectif est de repousser l’obsolescence de machines qui tournent encore très bien, l’une de ces méthodes peut vous permettre de migrer vers Windows 11 sans changer de matériel immédiatement.

Créez un coffre géré par Veeam dans Azure

Depuis déjà plusieurs années, l’augmentation croissante des menaces, qu’il s’agisse de rançongiciels, de pannes matérielles ou d’erreurs humaines, impose de repenser ses stratégies de sauvegarde dans le cloud. Plutôt que de gérer soi-même un compte de stockage Azure, Veeam Data Cloud Vault se présente comme un coffre 100 % managé, conçu pour simplifier et fiabiliser vos sauvegardes tout en respectant la règle 3-2-1-1-0.

Un premier article parlant de la sauvegarde des données 365 via la solution Veeam Data Cloud SaaS Backup est disponible juste ici.

Dans cet article, je vous guide pas à pas pour déployer votre coffre Veeam depuis Azure Marketplace, l’intégrer à Veeam Backup & Replication et tirer pleinement parti de ses fonctionnalités avancées.

Qu’est-ce que le concept 3-2-1 pour les sauvegardes ?

Le concept de la règle 3-2-1 a été formalisé par le photographe numérique Peter Krogh, et publié pour la première fois en 2005 dans son ouvrage The DAM Book: Digital Asset Management for Photographers

Il s’agit d’une règle simple et éprouvée pour garantir la sécurité et la résilience de vos sauvegardes :

3 copies des données

  • 1 copie « live » : vos données actives sur le système de production
  • 2 copies de sauvegarde : répliquées ailleurs, pour pouvoir restaurer en cas de défaillance ou de corruption

2 types de supports différents

  • Par exemple :
    • Un disque dur interne ou réseau (NAS)
    • Un autre support : bande LTO, SSD externe, ou stockage objet cloud
  • L’idée est de réduire le risque de défaillance matérielle simultanée : un même lot de disques peut tomber en panne, mais un disque dur + une bande ou un système cloud présentent des modes de panne différents.

1 copie hors site

  • Pour vous prémunir contre :
    • Vol, incendie ou inondation de votre site principal
    • Corruption logicielle ou rançongiciel (ransomware) qui toucherait tout votre réseau
  • Cette copie peut être :
    • Hébergée dans un cloud public (Azure Blob Storage, Amazon S3, etc.)
    • Stockée physiquement dans un autre bureau ou un coffre-fort externe
    • Répliquée chez un prestataire spécialisé

Et pourquoi parle-t-on maintenant de 3-2-1-1-0 ?

Le concept 3-2-1-1-0 est une évolution de la règle 3-2-1, pensée pour les menaces modernes (ransomware, erreurs de sauvegarde, etc.). Il rajoute ainsi :

1 copie hors ligne ou immuable (air-gapped/immutable).
Cette copie n’est pas connectée au réseau (ou est protégée en écriture seule), de manière à rester intacte même en cas de ransomware ciblant vos systèmes connectés.

0 erreur de sauvegarde.
Il faut vérifier régulièrement que chaque sauvegarde se termine sans erreur, et tester la restauration pour garantir l’intégrité et la disponibilité de vos données en cas de besoin.

Qu’est-ce que Veeam Data Cloud vault ?

Veeam Data Cloud Vault est un service de stockage cloud sécurisé, pré-configuré et entièrement géré par Veeam sur l’infrastructure Microsoft Azure. Voici une courte vidéo qui vous montre ce service :

Pourquoi passer par Veeam Data Cloud Vault à la place de créer directement un compte de stockage Azure ?

La configuration faite directement par Veeam est le premier avantage à passer par le service Veeam Data Cloud Vault : vous indiquez simplement votre volume de données à sauvegarder, et tout est provisionné sans aucun paramétrage Azure de votre part.

Voici ce que Veeam fait automatiquement pour vous :

Immutabilité et isolation « Zero Trust » intégrées
Veeam Data Cloud Vault repose sur des mécanismes d’immutabilité natifs : chaque objet écrit devient en lecture seule pour la durée configurée, empêchant toute suppression ou modification accidentelle ou malveillante (ransomware). Cette couche d’isolation logique (air-gapped, c’est-à-dire isolée du réseau) est activée par défaut et n’existe pas automatiquement sur un compte de stockage classique sans configuration manuelle

Sécurité et chiffrement bout en bout
Les transferts entre Veeam Backup & Replication et le Vault se font sur des canaux chiffrés via un certificat mutualisé, sans jamais exposer de clés ou de tokens. De plus, toutes les données sont stockées chiffrées au repos, sans configuration supplémentaire. Un compte de stockage classique exige la mise en place manuelle du chiffrement (Azure Storage Service Encryption) et la gestion des clés (Key Vault)

Conformité à la stratégie 3-2-1-1-0
Le Vault répond directement aux exigences :

  • 1 copie hors site : vos backups sont sur l’infrastructure Veeam dans Azure.
  • 1 copie immuable/air-gapped : garantie par la politique d’immutabilité native.
  • 0 erreur : Veeam supervise automatiquement la réussite de chaque sauvegarde et vous alerte en cas de problème.

Un compte de stockage classique n’offre pas cette orchestration automatisée autour de la vérification d’intégrité et de l’immutabilité.

Combien coûte Veeam Data Cloud Vault ?

La partie des coûts proposée par Veeam s’avère intéressante. Contrairement au modèle « pay-as-you-go » (à l’usage) habituellement appliqué à un compte de stockage Azure, Veeam Data Cloud Vault propose un tarif forfaitaire par To incluant le stockage, les appels API, l’egress et les restaurations : plus de risque de « bill shock » lié aux opérations ou au trafic.

Deux SKUs sont proposés par Veeam : Foundation et Advanced :

  • Foundation débute à 14 USD / To / mois (facturé annuellement).
  • Advanced est à 24 USD / TB / mois, mais inclut un nombre illimité d’opérations de lecture/restauration.

On peut différencier ces deux offres de la façon suivante :

  • Granularité de l’emplacement
    • Foundation vous permet de choisir le pays où vos données seront stockées, Veeam/Microsoft sélectionnant ensuite la région exacte.
    • Advanced vous donne la main sur la région Azure précise (par exemple « West Europe » vs « North Europe ») pour optimiser latence, conformité ou réplication inter-zones.
  • Durabilité
    • Foundation s’appuie sur LRS (Locally Redundant Storage), garantissant « 11 nines » de durabilité (99,999999999 %).
    • Advanced utilise ZRS (Zone-Redundant Storage), offrant « 12 nines » (99,9999999999 %) en répartissant les données sur plusieurs zones de disponibilité.
  • Limites de lecture/restauration
    • Foundation applique une politique de fair use sur les appels de lecture et les restaurations.
    • Advanced propose des lectures et restaurations illimitées sans restrictions supplémentaires.

Qu’est-ce que contient le Fair Use de Veeam ?

La politique Fair Use de Veeam Data Cloud Vault définit une franchise gratuite d’opérations de lecture/restauration incluse dans votre abonnement, afin d’assurer une utilisation raisonnable et équitable des ressources :

  • Foundation Edition :
    Restauration ou récupération de données jusqu’à 20 % de la capacité totale souscrite sur une période d’un an, sans surcoût.
  • Advanced Edition :
    Restauration ou récupération de données jusqu’à 100 % de votre capacité activement consommée chaque année, sans surcoût.

Au-delà de ces seuils, les opérations de lecture, de récupération et l’egress sont facturés aux tarifs standards Microsoft applicables à la région concernée.

Quelles régions Azure supportent Veeam Data Cloud Vault ?

Voici les régions Azure prises en charge par Veeam Data Cloud Vault :

Comment tester Veeam Data Cloud Vault ?

De nombreuses vidéos sont déjà disponibles sur la chaîne YouTube de Veeam :

Voici les différentes étapes que nous allons suivre afin de tester la solution Veeam Data Cloud Vault sur un environnement de test :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Afin de réaliser nos tests sur Veeam Data Cloud Vault, nous allons avoir besoin de :

  • Un tenant Microsoft actif
  • Une souscription Azure valide

Commençons par déployer la solution depuis Azure Marketplace.

Etape I – Déploiement de Veeam Data Cloud Vault :

Depuis le portail Azure, recherchez Veeam Data Cloud Vault :

Déployez la solution SaaS dans la souscription, le groupe de ressources et la nom de votre ressource :

Ouvrez la liste des plans disponibles :

Changez votre plan si nécessaire :

Lancez la validation Azure :

Une fois la validation réussie, lancez la création de la solution :

Attendez quelques minutes le temps de la configuration de Veeam Data Cloud Vault :

Une fois la configuration terminée, cliquez sur le bouton de finalisation :

Vérifiez les informations affichées, puis cliquez-ici pour activer la souscription. Selon ma compréhension, l’activation de celle-ci déclenche la facturation sur votre souscription Azure. Vous disposez alors de 72 heures pour vous rétracter une fois celle-ci activée :

Une fois la souscription Veeam activée, cliquez-ici pour basculer sur la console de gestion Veeam Data Cloud Vault :

Choisissez une authentification via Entra ID :

Veeam vous propose de créer votre premier coffre, vérifiez les informations puis cliquez sur Suivant :

Etant parti sur le plan Foundation, choisissez le Pays et non la région Azure, puis cliquez sur Suivant :

Attendez quelques minutes le temps du provisionnement et de la configuration des ressources gérées par Veeam :

Quelques minutes plus tard, le coffre Veeam est créé, copiez les informations suivantes afin de configurer votre application Veeam Backup :

Cliquez sur Suivant afin de terminer la configuration :

La fin de la configuration vous transporte sur le tableau de bord de Veeam Data Cloud Vault :

Du côté d’Azure, vous pouvez constater la ressource SaaS dans le groupe de ressources ; cliquez dessus pour retrouver le détail de la solution :

Un clic sur le lien de cette solution vous permet d’ouvrir l’URL d’accueil de Veeam Data Cloud Vault :

Un autre clic sur le lien ci-dessous vous ouvre votre propre instance de Veeam Data Cloud Vault :

Consultez ou créez au besoin vos coffres sur cette page :

Visualisez les souscriptions Azure sur cet écran :

Le volume de stockage est visible depuis ce même portail après un rafraîchissement de l’information :

L’information est visible sur ce portail après une ou plusieurs heures :

Les informations du volume total de stockage sont alors actualisées sur le tableau de bord principal :

Notre solution Veeam Data Cloud Vault est maintenant configurée et prête à recevoir des données. La prochaine étape consiste à configurer cette dernière depuis un outil de sauvegarde, comme Veeam Backup & Replication.

Etape II – Ajout d’un coffre Veeam :

J’ai créé une machine virtuelle depuis le Marketplace Azure la solution Veeam Backup & Replication pour réaliser les tests.

Une fois la console de gestion de Veeam Backup & Replication ouverte, ouvrez la configuration de l’infrastructure de sauvegarde :

Cliquez sur le type Veeam Data Cloud Vault :

Nommez celui-ci, cochez la case, puis cliquez sur Suivant :

Cliquez sur Ajouter, puis choisissez la connexion avec la clef du coffre :

Collez les informations précédemment copiées du coffre Veeam, puis cliquez sur OK :

Cliquez sur Suivant :

Renseignez un nouveau dossier créé sur le coffre, puis cliquez sur Suivant :

Définissez les informations du stockage local pour les restaurations rapides, puis cliquez sur Suivant :

Cliquez sur Appliquer :

Attendez quelques secondes la mise en place de la configuration, puis cliquez sur Suivant :

Une fois la configuration réussie, cliquez sur Terminer :

Constatez l’apparition du coffre dans la liste des répertoires de Sauvegarde :

Notre coffre Veeam est maintenant un répertoire de sauvegarde. Nous allons maintenant modifier une première police consacrée à la sauvegarde d’un partage de fichiers.

Etape III – Sauvegarde d’un partage de fichier sur le coffre Veeam :

Pour cela, retournez dans les travaux de sauvegarde déjà en place, puis cliquez sur l’un d’entre eux afin de le modifier :

Cochez la case suivante afin de configurer le coffre Veeam comme seconde destination de sauvegarde :

Cliquez sur Avancé :

Cochez la case suivante, configurez un mot de passe, puis cliquez sur OK :

Ajoutez en seconde cible le coffre Veeam, puis cliquez termine la modification de la police de sauvegarde :

Constatez l’apparition d’un second travail de sauvegarde, dont le déclenchement dépendra du premier auquel il est rattaché :

Lancez le premier travail de sauvegarde afin de tester le bon fonctionnement :

Une fois le premier travail de sauvegarde terminé, constatez le démarrage automatique du second travail de sauvegarde dédié au coffre Veeam :

Constatez l’apparition de sauvegarde du partage de fichiers et du nombre de points de restauration disponibles :

Retournez sur les répertoires de sauvegarde afin de visualiser la consommation d’espace sur votre coffre Veeam :

Testons maintenant la même approche de réplication de sauvegarde pour un stockage objet.

Etape IV – Sauvegarde d’objets sur le coffre Veeam :

Retournez à nouveau dans les travaux de sauvegarde objet déjà en place, puis cliquez sur l’un d’entre eux afin d’ajouter comme seconde destination de sauvegarde le coffre Veeam.

Cliquez sur Avancé :

Cochez la case suivante, configurez un mot de passe, puis cliquez sur OK :

Ajoutez en seconde cible le coffre Veeam, puis cliquez termine la modification de la police de sauvegarde :

Constatez l’apparition d’un second travail de sauvegarde, dont le déclenchement dépendra du premier auquel il est rattaché :

Lancez le premier travail de sauvegarde afin de tester le bon fonctionnement, puis constatez l’apparition de sauvegardes de fichiers objets :

Retournez sur les répertoire de sauvegarde afin de visualiser l’augmentation de la consommation d’espace sur votre coffre Veeam :

Terminons notre test par la restauration d’un fichier objet supprimé dans un conteneur Azure, dont la sauvegarde est répliquée sur le coffre Veeam.

Etape V – Restauration d’un fichier objet :

Supprimez un fichier sur un stockage objet :

Depuis Veeam Backup & Replication, retournez sur les points de sauvegarde associés au coffre Veeam, puis lancez la restauration d’un fichier objet :

Attendez quelques secondes le chargement des points restauration disponibles :

Cliquez sur le fichier supprimé à restaurer, puis déclenchez la restauration par écrasement :

Attendez quelques secondes le déclenchement du travail de restauration :

Attendez quelques minutes la fin du travail de restauration :

Constatez la réapparition du fichier sur le stockage objet :

Conclusion

En adoptant Veeam Data Cloud Vault sur Azure, vous déléguez la complexité opérationnelle et garantissez une protection de vos données conforme à la règle 3-2-1-1-0 :

  • Déploiement en un clic : plus besoin de scripts ni d’ARM templates.
  • Sécurité renforcée : immutabilité native et chiffrement bout-en-bout activés par défaut.
  • Surveillance proactive : Veeam supervise vos jobs et vous alerte immédiatement en cas d’anomalie.
  • Prévisibilité budgétaire : un tarif fixe par To incluant toutes les opérations et l’egress, sans surprises.

Que vous choisissiez l’édition Foundation ou Advanced, Veeam vous offre une solution SaaS prête à l’emploi, alliant performance, sécurité et tranquillité d’esprit 😎

Enfin Veeam propose même un vidéo de la configuration en mode démo :

Sauvegardez vos données 365 avec VDC de Veeam

Depuis 2024, Microsoft propose une solution de sauvegarde directement intégrée à Microsoft 365. Cette solution apporte une couche de sécurité pour les informations stockées sur SharePoint, OneDrive et Exchange. Un article est d’ailleurs disponible ici. Mais que propose Veeam comme solution de sauvegarde SaaS pour protéger à son tour les données 365 ?

Comme bien d’autres éditeurs spécialisés dans la sauvegarde, Veeam propose justement un produit SaaS pour répondre à ce besoin : Veeam Data Cloud for Microsoft 365.

Qu’est-ce que Veeam Data Cloud SaaS Backup ?

Veeam Data Cloud for Microsoft 365 (VDC) est une solution BaaS (Backup as a Service) conçue pour protéger et restaurer de manière sécurisée les données hébergées dans le cloud Microsoft et dans certaines autres applications SaaS.

Veeam résume sa solution en quelques points :

  • Accès aux services Veeam Data Cloud depuis un navigateur web ;
  • Le coût du stockage des sauvegardes est inclus dans l’abonnement, avec stockage illimité ;
  • Choix de la région Azure préférée pour héberger les sauvegardes ;
  • Veeam ajuste automatiquement les ressources cloud sans frais supplémentaires ;
  • Aucun frais additionnel pour les opérations de restauration ;
  • Après annulation ou résiliation de l’abonnement, les sauvegardes restent disponibles pendant 30 jours supplémentaires ;
  • Le support technique de l’ensemble du service est 100 % assuré par Veeam.

Dois-je déployer des ressources dans Azure ?

Non, car Veeam Data Cloud for Microsoft 365 est une solution 100 % SaaS. Elle inclut le logiciel, l’infrastructure de sauvegarde et le stockage. Tout est directement géré par Veeam.

Contrairement à la solution Veeam Backup for Microsoft 365 disponible sur Azure Marketplace, avec VDC vous n’avez rien à provisionner :

vous vous connectez simplement via une interface web pour créer vos tâches de sauvegarde, définir vos politiques de rétention et lancer vos restaurations, sans vous soucier du provisionnement ni de la maintenance de l’infrastructure sous-jacente.

Quels sont les différents plans possibles ?

Veeam Data Cloud for Microsoft 365 propose trois formules : Express, Flex et Premium. Toutes les fonctionnalités sont détaillées ici :

  • Express s’appuie exclusivement sur le Microsoft 365 Backup Storage pour offrir des sauvegardes ultrarapides et des restaurations en masse, sans limitation de débit ;
  • Flex utilise un compte Azure Storage dédié, géré par Veeam, avec choix de la région et granularité de restauration (fichiers, versions, recherches avancées…) ;
  • Premium combine la vitesse et l’échelle d’Express avec le contrôle, la flexibilité et la granularité de Flex, le tout dans une même interface.

En résumé :

Express = vitesse (M365 Backup Storage) ;
Flex = autonomie et granularité (Azure Storage géré par Veeam) ;
Premium = les deux mondes réunis.

Voici un tableau comparatif de prix de ces trois plans en engagement mensuel :

Et voici un tableau comparatif de prix de ces trois plans en engagement annuel :

Comment est-on facturé par Veeam ?

La facturation de Veeam Data Cloud for Microsoft 365 se fait à l’usage et dépend du type de charge de travail protégé.

Vous pouvez souscrire via Azure Marketplace, des revendeurs ou des Veeam Cloud & Service Providers. Selon le canal et le contrat, vous pouvez opter pour un paiement anticipé (abonnement annuel ou multi-annuel) ou un paiement en arriéré, basé sur la consommation mensuelle.

Comment et où la donnée est sauvegardée ?

Dans Veeam Data Cloud SaaS Backup, vos sauvegardes et les options disponibles dépendent du plan choisi :

  • Express : pas de choix d’emplacement ; plusieurs copies redondantes dans la limite de sécurité Microsoft.
  • Flex : sélection de la région de stockage Azure souhaitée ; copies redondantes et sauvegarde distincte dans une autre région Azure.
  • Premium : sélection de la région de stockage Azure souhaitée ; respect strict de la règle 3-2-1 avec plusieurs options de sauvegarde et de restauration.

Comment tester Veeam Data Cloud SaaS Backup ?

Voici les différentes étapes que nous allons suivre afin de tester la solution Veeam Data Cloud SaaS Backup sur un environnement Microsoft 365 de test :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Afin de réaliser nos tests sur Veeam Data Cloud SaaS Backup, nous allons avoir besoin de :

  • Un tenant Microsoft actif
  • Une souscription Azure valide

Commençons par déployer la solution depuis Azure Marketplace.

Etape I – Déploiement de VDC :

Depuis le portail Azure, recherchez Veeam Data Cloud for Microsoft 365 :

Déployez la solution SaaS dans la souscription, le groupe de ressources et la région Azure de votre choix :

Choisissez votre plan, puis lancez la validation Azure :

Une fois la validation réussie, créez la solution :

Attendez quelques minutes le temps de la configuration de Veeam Data Cloud SaaS Backup :

La notification Azure apparaît alors :

Une fois la configuration de Veeam Data Cloud SaaS Backup terminée, la notification Azure se met à jour :

Retournez dans le groupe de ressources Azure utilisé par votre solution SaaS, puis cliquez dessus :

Un détail de la souscription achetée s’affiche alors :

Cliquez sur le bouton de finalisation de la configuration :

Définissez votre région :

Vérifiez le plan souscrit :

Renseignez les informations de votre entreprise, puis cliquez sur Soumettre :

Une fois la souscription VDC activée, cliquez sur ici pour basculer sur la console de gestion :

Liez l’authentification avec votre Azure AD (Entra ID) en acceptant les autorisations :

Cliquez sur Acceptez :

Acceptez les conditions d’utilisations de VDC :

Définissez les notifications souhaitées par VDC, puis cliquez sur Suivant :

Pour vos données, choisissez :

  • la région Azure de votre choix,
  • la durée de rétention des données,

Puis copiez le code donnée afin d’effectuer une délégation d’authentification :

Dans ce nouvel onglet, collez le code précédemment copié, puis cliquez sur Suivant :

Authentifiez-vous avec un compte administrateur global de votre tenant :

Cliquez sur Acceptez :

Une fois l’authentification réussie, vous pouvez fermer cet onglet :

Les deux applications Veeam précédemment acceptées sont alors visibles :

Continuez la configuration de VDC en cliquant sur Connecter :

Définissez le modèle d’adaptation de nombre de licences VDC, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez-ici pour créer votre propre police de sauvegarde VDC :

Confirmez votre choix en cliquant sur Non :

Notre environnement VDC est maintenant en place et opérationnel. Comme nous avons décidé de créer notre propre police de sauvegarde, nous avons besoin d’en créer une pour définir quelles données 365 doivent être sauvegardées.

Etape II – Configuration de la police de sauvegarde :

Depuis ce menu, cliquez-ici pour créer une nouvelle police de sauvegarde VDC :

Nommez votre police de sauvegarde, puis cliquez sur Suivant :

Définissez les objets à sauvegarder (Exchange, OneDrive, SharePoint, Teams…), puis cliquez sur Créer :

La politique apparaît dans la liste :

Consultez le menu Facturation pour voir les licences consommées :

Retournez sur votre police VDC, puis démarrez celle-ci :

Attendez la fin de traitement de celle-ci :

Attendez le changement de statut, ainsi que l’apparition des menus dédiés à la sauvegarde dans la section de gauche :

Cliquez sur votre police afin de constater les différents points de sauvegarde :

Retournez dans le menu du tableau de bord afin de voir les informations mises en avant par VDC :

En bas de ce tableau de bord figurent les types de données sauvegardées ainsi qu’un journal d’activités des utilisateurs :

Retournez dans le menu de facturation afin de voir les licences nouvellement consommées :

Affichez le détail des licences consommées par utilisateur :

Il est même possible d’effectuer une liaison de type webhook dans Teams :

Les opérations de restauration entraînent alors l’apparition d’un message dans Teams :

Notre police de sauvegarde est maintenant en place et données ont déjà été sauvegardées. Testons maintenant la partie restauration des données sur différents services de Microsoft 365.

Etape III – Tests de restauration :

Commencez par effectuer un test de restauration en supprimant un ou plusieurs messages dans votre messagerie Outlook :

Sur la console VDC, retournez sur le type de données Outlook, puis laissez-vous guider dans la restauration :

Prévisualisez au besoin le ou les e-mails à restaurer :

Cliquez sur Restaurer pour démarrer le processus :

La notification suivante de VDC apparaît alors :

L’activité de restauration est conservée et visible ici :

Retournez dans votre messagerie Outlook afin de constater le retour des e-mails restaurés :

Effectuez un test de restauration en supprimant un ou plusieurs fichiers dans votre compte OneDrive :

Sur la console VDC, retournez sur le type de données OneDrive, puis laissez-vous guider dans la restauration comme pour Outlook :

Retournez sur votre compte OneDrive afin de constater le retour des fichiers restaurés :

Effectuez un test de restauration en supprimant un ou plusieurs fichiers dans l’une de vos équipes Teams :

Sur la console VDC, retournez sur le type de données Teams, puis laissez-vous guider dans la restauration comme pour Outlook :

Retournez sur votre équipe Teams afin de constater le retour des fichiers restaurés :

Il en sera de même pour la restauration de fichiers ou de données SharePoint :

Enfin, il existe également une fonction de recherche globale, très pratique pour retrouver la données à restaurer :

La sauvegarde de certaines données 365 nécessite une configuration supplémentaire. Par exemple, il est également possible d’activer en plus la sauvegarde des messages des chats Teams.

Etape IV – Sauvegarde des chats Teams :

Pour cela, rendez-vous dans l’application VDC automatiquement créée et visible dans votre portail Entra ID, puis copiez l’ID de votre application :

Retournez dans la console VDC afin d’activer la sauvegarde des chats Teams :

Depuis le portail Azure, ouvrez le Cloud Shell :

Saisissez la commande suivante afin de créer un accès Graph payant en replaçant les valeurs en gras :

az graph-services account create --resource-group VOTRE_RG --resource-name myGraphAppBilling --subscription VOTRE_SUB --location global --app-id VOTRE_APP_ID 

Confirmez l’action avec Y :

Obtenez le résultat de commande suivant :

La ressource Graph est alors visible sur dans votre groupe de ressources :

Retournez sur la console VDC afin de modifier votre police de sauvegarde afin d’y inclure les chats :

Après une nouvelle sauvegarde des données, consultez les messages de chat Teams sauvegardés par VDC :

Conclusion :

Veeam Data Cloud for Microsoft 365 offre une solution de sauvegarde complète et clé en main pour protéger vos environnements Microsoft 365 sans devoir gérer ni provisionner d’infrastructure.

Son déploiement via le portail Azure est rapide et intuitif, et la console web Veeam centralise la création des politiques de sauvegarde, le suivi des activités et l’exécution des restaurations, qu’il s’agisse de mails Outlook, de fichiers OneDrive, …

Grâce à ses trois formules (Express, Flex et Premium), vous pouvez adapter la sauvegarde à vos besoins de rapidité, de contrôle et de granularité, tout en bénéficiant d’un stockage inclus et d’une facturation à l’usage.

Faites du NAT avec Azure VPN

Dans un contexte où la migration vers le cloud s’accompagne souvent de contraintes d’adressage et de sécurité, le NAT peut être vu comme une solution pouvant résoudre les problématiques de chevauchement d’adresses et de confidentialité. Vraiment ?

Attention ! Recourir au NAT pour masquer des conflits d’adresses n’est pas toujours une approche saine à long terme, car cela peut introduire une complexité opérationnelle accrue et des difficultés de maintenance ; il doit donc être considéré comme une solution transitoire ou de contournement.

Qu’est-ce que le NAT ?

Le NAT ( ou Network Address Translation) est un mécanisme qui permet de faire correspondre des adresses IP privées (non routables sur Internet) à une ou plusieurs adresses IP publiques (routables). Il joue un rôle clé dans la conservation des adresses IPv4 et dans la sécurisation des réseaux privés.

Voici une courte vidéo qui explique le principe du NAT afin de pallier le souci d’adresses IPv4 pour Internet :

Comment fonctionne le NAT ?

Lorsqu’une machine interne (par exemple 10.0.0.1) envoie une requête vers Internet (par exemple 200.100.10.1), le routeur NAT remplace son adresse source privée par une adresse publique (par exemple 150.150.0.1), et stocke dans sa table de traduction la corrélation :

Le routage du trafic impacte alors le traffic de données dans les deux sens :

  • Sortant : le paquet quitte le réseau interne avec l’adresse publique.
  • Entrant : la réponse revient à l’adresse publique, le routeur NAT consulte sa table et renvoie le paquet à la machine interne d’origine.

Quels sont ses avantages et ses limites au NAT ?

Avantages

  • Économie d’adresses IPv4
  • Masquage du réseau interne (sécurité renforcée)
  • Contrôle centralisé du trafic sortant/entrant

Limites

  • Complexité de dépannage (tables de traduction)
  • Certains protocoles (FTP actif, SIP, etc.) nécessitent des algorithmes NAT-aware ou des « NAT helpers »
  • Impact potentiel sur la latence et le débit

SNAT vs DNAT ?

En pratique, le NAT (Network Address Translation) se décline en deux grands modes :

ModeAbréviationFonction principaleExemple d’usage
Source NATSNAT (Source NAT)Modifier l’adresse source et/ou le port d’une connexion sortanteVotre VM privée (10.0.0.5) → Internet apparaît avec l’IP publique du NAT Gateway
Destination NATDNAT (Destination NAT)Modifier l’adresse de destination et/ou le port d’une connexion entranteInternet (51.210.34.12:80) → redirigé vers votre VM privée (10.0.0.5:8080)
  • Règles de NAT sortantes : permettent de présenter votre réseau virtuel Azure à vos sites distants avec un plan d’adressage spécifique.
  • Règles de NAT entrantes : permettent à vos sites distants d’accéder au réseau virtuel Azure en utilisant un plan d’adressage différent.

Et le NAT dans Azure c’est possible ?

Un premier service, appelé Azure NAT Gateway, est conçu pour offrir un moyen simple, fiable et évolutif de gérer le trafic sortant depuis vos réseaux virtuels vers Internet ou d’autres services Azure, sans exposer vos machines virtuelles (VM) directement avec des adresses IP publiques :

Une passerelle NAT Azure est un service de traduction d’adresses réseau entièrement managé et hautement résilient. Vous pouvez utiliser Azure NAT Gateway pour autoriser toutes les instances d’un sous-réseau privé à se connecter à Internet, tout en restant entièrement privées. Les connexions entrantes non sollicitées depuis Internet ne sont pas autorisées via une passerelle NAT. Seuls les paquets arrivant en tant que paquets de réponse à une connexion sortante peuvent passer via une passerelle NAT.

Microsoft Learn

Quels services Azure proposent du NAT ?

Oui, plusieurs services Azure permettant de faire du NAT entre votre réseau Azure et votre infrastructure on-premise :

Peut-on donc avoir un chevauchement d’adresses entre le LAN et un réseau virtuel Azure ?

La réponse est oui :

Les organisations utilisent fréquemment des adresses IP privées définies dans le document RFC1918 pour la communication interne dans leurs réseaux privés. Quand ces réseaux sont connectés à l’aide d’un VPN via Internet ou à l’aide d’un WAN privé, les espaces d’adressage ne doivent pas se chevaucher.

Si c’est le cas, la communication échoue. Pour connecter deux réseaux ou plus avec des adresses IP qui se chevauchent, le NAT est déployé sur les appareils de passerelle qui connectent les réseaux.

Microsoft Learn

Voici un exemple d’architecture entre plusieurs sites appliquant différentes règles NAT :

Attention, Microsoft liste ici les contraintes pour la fonctionnalité NAT d’Azure VPN Gateway :

  • NAT est pris en charge sur les références (SKU) suivantes : VpnGw2~5, VpnGw2AZ~5AZ.
  • NAT est pris en charge pour les connexions intersites IPsec/IKE uniquement. Les connexions de réseau virtuel à réseau virtuel et les connexions P2S (point à site) ne sont pas prises en charge.
  • Les règles NAT ne sont pas prises en charge sur des connexions pour lesquelles l’option Utiliser des sélecteurs de trafic basés sur des stratégies est activée.
  • La taille maximale du sous-réseau de mappage externe prise en charge pour le NAT dynamique est /26.
  • Les mappages de ports ne peuvent être configurés qu’avec des types NAT statiques. Les scénarios NAT dynamiques ne s’appliquent pas aux mappages de ports.
  • Les mappages de ports ne peuvent pas prendre de plages pour l’instant. Un port individuel doit être entré.
  • Les mappages de ports peuvent servir pour les protocoles TCP et UDP.

Et en pratique ?

Pour valider la fonctionnalité de NAT au sein de mon architecture Azure, j’ai mis en place un petit exercice de démonstration. Mon environnement se compose de deux réseaux distincts :

  • Le premier simulant un réseau on-premise
  • Le second correspondant à un réseau virtuel Azure

Le schéma ci-dessous présente ces deux réseaux créés dans mon environnement Azure :

Dans le portail Azure, j’ai donc créé deux réseaux virtuels configurés sur la même plage d’adressage (10.0.0.0/16) pour illustrer un cas de chevauchement :

Sur chaque réseau virtuel, j’ai provisionné une machine virtuelle, toutes les deux en 10.0.0.4 pour renforcer l’idée d’adressage complètement identique :

Pour établir la connectivité, j’ai déployé deux VPN Gateway de type VpnGw2, configurées en tunnel IPsec site à site entre elles :

J’ai commencé par ajouter des règles NAT sur la passerelle Azure :

  • Egress rules –> pour présenter votre réseau virtuel Azure avec un adressage translaté à votre réseau on-premise :
    • adresses internes : l’adressage IP configuré sur votre réseau virtuel Azure
    • adresses externes = l’adressage IP translaté vu par votre réseau on-premise
  • Ingress rules –> pour accéder à votre réseau on-premise avec des IP différentes de celles configurées :
    • adresses internes = l’adressage IP configuré sur votre réseau on-premise
    • adresses externes = l’adressage IP translaté vu par votre réseau virtuel Azure

J’ai répliqué la même logique avec une configuration opposée sur la passerelle VPN simulant celle de mon réseau on-premise :

  • Egress rules –> pour présenter ton réseau on-premise avec un adressage translaté à ton réseau virtuel Azure :
    • adresses internes : l’adressage IP configuré sur ton réseau on-premise
    • adresses externes = l’adressage IP translaté vu par ton réseau virtuel Azure
  • Ingress rules –> pour accéder à ton réseau virtuel Azure avec des IP différentes de celles configurées :
    • adresses internes = l’adressage IP configuré sur ton réseau virtuel Azure
    • adresses externes = l’adressage IP translaté vu par ton réseau on-premise

Enfin, j’ai créé deux passerelle de réseau local correspondant à chaque extrémité :

  • L’une pour présenter le réseau on-premise à la passerelle Azure
  • L’autre pour présenter le réseau Azure la passerelle on-premise

La première passerelle de réseau local contient l’IP publique de la passerelle VPN Azure et la plage d’adresses 10.0.0.0/16 :

La seconde passerelle de réseau local contient l’IP publique de la passerelle VPN on-premise et la plage d’adresses 10.0.0.0/16 :

J’ai ensuite établi la connexion site-à-site entre mes deux VPN Gateways (VpnGw2) en utilisant la clé pré-partagée définie lors de la création des ressources.

Lors de la configuration de la première connexion, j’ai directement rattaché les règles Ingress NAT et Egress NAT définies précédemment à cette connexion, afin que toute session transitant par le tunnel soit automatiquement traduite.

J’ai reproduit la même configuration sur la seconde connexion : la clé PSK identique, la même plage 10.0.0.0/16 et les règles NAT :

Pour faciliter la connexion de la VM hébergée dans le réseau virtuel Azure, j’ai ajouté le service Azure Bastion :

Une fois Azure Bastion en place, je me suis connecté à la machine virtuelle Azure directement depuis le portail :

Depuis la machine virtuelle Azure, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la VM simulée on-premise :

Depuis le même service Azure Bastion déployé sur le réseau virtuel Azure, j’ai ouvert une session RDP vers la machine virtuelle simulée sur le réseau on-premise en utilisant l’adresse IP externe traduite définie dans les règles NAT de la connexion VPN :

Depuis la VM simulée on-premise, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la machine virtuelle Azure :

Conclusion

Grâce à l’association d’Azure VPN Gateway et de règles SNAT, nous avons validé une communication bidirectionnelle transparente entre deux environnements au plan d’adressage identique, sans exposer d’IP publiques aux VM. Cette démonstration illustre la puissance du NAT dans Azure pour contourner le chevauchement d’adresses

Notez toutefois que s’appuyer durablement sur le NAT peut complexifier votre architecture et alourdir le dépannage ; il est donc recommandé de considérer cette solution comme une étape temporaire, en prévoyant à terme une refonte de votre plan d’adressage pour une architecture plus saine.

Installation d’EnergyBoard

EnergyBoard peut être déployé aussi bien dans le cloud, via une machine virtuelle Azure, que sur un serveur local compact comme un Raspberry Pi 5. Dans les deux cas, il faudra passer par quelques manipulations en ligne de commande (installation de Node.js, configuration du service, ouverture des ports, etc.) pour lancer et sécuriser le serveur. Sur Azure, vous bénéficiez de la haute disponibilité sans contrainte matérielle, mais vous resterez cantonné aux appels API cloud.

Etape 0 – Rappel des prérequis :

Pour déployer EnergyBoard sur votre environnement (Machine virtuelle Azure ou Raspberry Pi 5), il vous faudra disposer de :

  • Une machine virtuelle Azure ou Raspberry Pi 5 en local
  • Un accès SSH à l’environnement
  • Installation de Teslamate réussie sur l’environnement

Avant de configurer EnergyBoard, commençons par copier les fichiers de l’application sur l’environnement.

Etape I – Transfert des fichiers EnergyBoard :

Créez un nouveau répertoire nommé energyboard dans le répertoire courant, puis déplacez-vous dans ce répertoire :

Utilisez des outils de transfert comme WinSCP, disponible à cette adresse :

Installez l’application WinSCP sur votre poste, puis authentifiez-vous à votre environnement via le protocol SFTP :

Copiez le contenu du fichier ZIP dans le dossier energyboard créé précédemment :

Avant de pouvoir démarrer l’application EnergyBoard, d’autres composants doivent être mis à jour sur notre environnement.

Etape II – Mise à jour de l’environnement :

Téléchargez et synchronisez la liste des paquets disponibles à partir des dépôts configurés sur votre environnement, permettant ainsi à apt de connaître les versions les plus récentes des logiciels et leurs dépendances avant une installation ou mise à jour :

sudo apt update

Installez les 2 logiciels essentiels pour notre application EnergyBoard tournant sous JavaScript :

  • nodejs : C’est l’environnement d’exécution permettant d’exécuter du code JavaScript côté serveur.
  • npm (Node Package Manager) : C’est le gestionnaire de paquets associé à Node.js, qui facilite l’installation, la mise à jour et la gestion des modules et bibliothèques JavaScript.
sudo apt install nodejs npm

Affichez les versions installées :

node -v
npm -v

Installez également PM2. Ce dernier est un outil qui permet de gérer, superviser et redémarrer automatiquement vos applications Node.js en production.

sudo npm install -g pm2

Ensuite, passer la commande suivante :

PORT=8002 pm2 start server.js --name energyboard

Celle-ci définit d’abord la variable d’environnement PORT sur 8002, puis lance le script server.js avec PM2, en lui attribuant le nom energyboard pour faciliter sa gestion (surveillance, redémarrage automatique, etc.) :

Configurez votre environnement pour démarrer automatiquement PM2 au démarrage de ce dernier :

pm2 startup

Enregistrez l’état actuel de vos applications surveillées par PM2 :

pm2 save

Ouvrez un navigateur internet afin d’accéder à votre application EnergyBoard :

http://4.251.124.83:8002/

Si celle-ci démarre bien, retournez sur votre environnement pour arrêter l’application afin de terminer la configuration :

pm2 stop energyboard

Retournez sur WinSCP afin d’éditer le nouveau fichier de configuration, présent dans le dossier suivant :

energyboard/assets/conf/config.json

Double-cliquez pour modifier ce fichier :

Configurez les éléments liés à votre installation Enphase :

Si vous souhaitez communiquez à votre Tesla uniquement via BLE :

  • Suivez la procédure de configuration BLE
  • Configurez les éléments suivants :

Si vous souhaitez communiquez à votre Tesla uniquement via API :

  • Suivez la procédure de configuration API
  • Configurez les éléments suivants :

Si vous souhaitez communiquez à votre Tesla via API et BLE :

  • Suivez la procédure de configuration API
  • Suivez la procédure de configuration BLE
  • Configurez les éléments suivants :

Pensez à sauvegarder le fichier de configuration via la commande suivante :

:wq

Redémarrer une fois les conteneurs Docker :

docker compose restart

Démarrer l’application EnergyBoard :

pm2 start energyboard

Rouvrez un navigateur internet afin d’accéder à votre application EnergyBoard :

http://4.251.124.83:8002/

EnergyBoard est maintenant installé, vous pouvez passer à l’étape suivante, consistant à installer et configurer la liaison Bluetooth avec la Tesla. Cette dernière va nous permettre de :

  • Envoyer des ordres Tesla via BLE grâce l’’agent ‘application Tesla-command

Etape suivante : Création de la connexion BLE Tesla

Optionnelle : Création de la connexion API Tesla

Cette étape est probablement la plus délicate de tout le processus. Prenez le temps de bien respecter les différentes opérations pour assurer un enrôlement réussi de votre API auprès de chez Tesla.

Qu’est-ce que Fleet API ?

Fleet API est un service de données et de commande qui donne accès aux véhicules Tesla, à l’énergie et à d’autres types d’appareils. Les partenaires peuvent interagir avec leurs propres appareils ou avec les appareils auxquels un client leur a donné accès.

Suivez le processus d’intégration ci-dessous pour vous inscrire et obtenir une clé API afin d’interagir avec les points d’extrémité de l’API de Tesla. Les applications peuvent demander aux propriétaires des véhicules l’autorisation de consulter les informations du compte, d’obtenir l’état du véhicule ou même d’émettre des commandes à distance.

Les propriétaires de véhicules contrôlent les applications auxquelles ils accordent l’accès et peuvent modifier ces paramètres à tout moment.

Tesla

Quelles sont les différentes étapes pour faire fonctionner Fleet API ?

Voici la liste des étapes que nous allons faire ensemble :

Etape 0 – Rappel des prérequis :

Pour mettre en place une connexion API sur votre environnement (Azure ou Raspberry Pi 5), il vous faudra disposer de :

  • Un compte Tesla
  • Une machine virtuelle ou Raspberry Pi 5
  • Un accès SSH à votre environnement

Avant de créer notre application API chez Tesla, commençons par configurer Ngork.

Etape I – Configuration de Ngrok :

Pour pouvoir enregistrer notre application chez Tesla, nous allons avoir besoin d’un domaine internet pointant sur notre clef publique.

Ngrok est un outil de tunnellisation qui permet d’exposer de manière sécurisée un serveur local à Internet via une URL publique, sans avoir à configurer manuellement votre réseau ou à ouvrir des ports dans votre pare-feu.

Pour cela, rendez-vous sur le site de Ngrok, puis inscrivez-vous chez eux afin d’avoir un compte gratuit :

Sur leur site, téléchargez l’installateur de Ngrok selon votre OS :

Copiez la commande suivante affichée sous l’installateur pour finaliser la configuration de votre Ngrok :

Depuis votre ordinateur, ouvrez Windows PowerShell :

Lancez la commande précédemment copiée afin de terminer la configuration Ngrok :

Créez un tunnel ngrok sécurisé depuis Internet vers votre serveur local qui écoute sur le port 80, en générant une URL publique accessible depuis n’importe quel navigateur :

ngrok http http://localhost:80

Copiez le nom de domaine commençant par https et finissant par ngrok-fre.app. Ne fermez pas cette fenêtre tant que le processus d’enrôlement API pas entièrement fini :

Ngrok est maintenant correctement configuré. L’étape suivante consiste à enregistrer notre application chez Tesla.

Etape II – Création de l’application API chez Tesla :

Rendez-vous le portail Développeur de Tesla, accessible via l’URL Tesla suivante, puis cliquez en haut à droite :

Cliquez ici pour créer votre compte Développeur Tesla :

Créez un compte en renseignant les champs de base, puis cliquez sur Suivant :

Renseignez votre mail ainsi qu’un mot de passe fort, puis cliquez sur Suivant :

Vérifiez votre compte via la réception d’un code par email :

Cliquez sur le bouton de configuration de la 2FA pour sécuriser votre compte, puis cliquez sur Continuer une fois l’enrôlement de la 2FA terminé :

Acceptez les conditions, puis cliquez sur Suivant :

Choisissez le premier choix, puis cliquez sur Suivant :

Renseignez tous les champs, puis cliquez sur Suivant :

Reprenez l’URL publique donnée par Ngrok, ajoutez en URL de redirection celle en-dessous, puis cliquez sur Suivant :

http://localhost:3000/callback

Cochez les cases suivantes, puis cliquez sur Suivant :

Cliquez sur Ignorer et soumettre :

La notification Tesla vous indiquant un succès de l’approbation de votre application API Tesla apparaît alors :

Un email de confirmation vous est également envoyé :

Votre application est immédiatement visible sur le portail de votre compte Développeur Tesla, cliquez-ici pour obtenir des informations techniques sur celle-ci :

Copiez l’ID et le secret de votre application car nous nous en aurons besoin plus tard :

Nous avons besoin de mettre à disposition la clef publique Tesla que nous avons généré quelques étapes plus tôt.

Etape III – Exposition de la clef publique API Tesla :

Pour cela, sur votre poste local, créez une arborescence de dossiers dans le lieu de votre choix, tant que la fin fini comme ceci :

.well-known\appspecific\

Ouvrez une session WinSCP vers votre environnement :

Récupérez la clef publique com.tesla.3p.public-key.pem générée précédemment afin de la placer dans le dossier créé sur votre poste local :

.well-known\appspecific\

Afin d’exposer cette clef publique, installez Python sur votre poste via l’URL officielle :

Ouvrez un nouvel onglet à Windows PowerShell, puis affichez la version de Python installée sur votre système

py --version

Utilisez Python pour démarrer le module intégré http.server sur le port 80

py -m http.server 80

Ne fermez pas cette fenêtre tant que le processus d’enrôlement API pas entièrement fini :

Depuis votre poste local, testez l’URL suivante afin de vérifier le bon téléchargement de votre clef publique API Tesla :

https://YOUR_NGROK_DOMAIN/.well-known/appspecific/com.tesla.3p.public-key.pem

Cliquez sur le bouton suivant pour confirmer votre action :

Constatez le téléchargement de votre clef publique sur votre poste local :

Nous sommes maintenant prêt à finaliser l’inscription de notre application chez Tesla.

Etape IV – Génération d’un token d’authentification partenaire :

Plusieurs requêtes API doivent être faites pour arriver au bout du processus. Pour cela, je vous conseille de passer par un outil local, comme Insomnia :

Insomnia REST est un client API (interface pour tester et déboguer des API) qui permet de créer, envoyer et gérer des requêtes HTTP et REST, ainsi que des requêtes GraphQL dans une interface graphique conviviale.

Chat GPT

Téléchargez la version selon votre OS :

Une fois Insomnia installé, créez un nouveau dossier pour y mettre toutes vos requêtes API Tesla :

Nommez votre dossier Insomnia, puis cliquez sur Créer :

Sur votre dossier Insomnia, effectuez un clique droit afin d’importer une requête API :

Collez le code ci-dessous en remplaçant en gras les valeurs par les vôtres, puis cliquez sur Importer :

curl --request POST \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode "client_id=CLIENT_ID" \
  --data-urlencode "client_secret=CLIENT_SECRET" \
  --data-urlencode 'scope=openid vehicle_device_data vehicle_cmds vehicle_charging_cmds' \
  --data-urlencode "audience=https://fleet-api.prd.eu.vn.cloud.tesla.com" \
  'https://fleet-auth.prd.vn.cloud.tesla.com/oauth2/v3/token'

Cette commande effectue une requête HTTP POST vers un endpoint OAuth2 afin d’obtenir un access token en utilisant le flux d’authentification client_credentials. Cela doit donner :

Nommez votre requête API pour plus de clarté, revérifiez tous les champs présent dans l’onglet Body, puis cliquez sur Envoyer :

Copiez l’accès token généré par Tesla pour une utilisation ultérieure. Continuons avec l’enregistrement de notre nom de domaine temporaire généré par Ngrok.

Etape V – Enregistrement d’un domaine chez Tesla :

Comme précédemment, effectuez un clique droit afin d’importer une nouvelle requête API :

Collez le code ci-dessous en remplaçant en gras les valeurs par les vôtres, puis cliquez sur Importer :

curl --request POST \
  --url https://fleet-api.prd.eu.vn.cloud.tesla.com/api/1/partner_accounts \
  --header 'Authorization: Bearer YOUR_PARTNER_ACCESS_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{"domain": "YOUR_NGROK_DOMAIN"}'

Cette commande effectue une requête HTTP POST vers l’API de la flotte de Tesla afin d’enregistrer ou de créer un compte partenaire avec un domaine spécifique. Cela doit donner :

Nommez votre requête API pour plus de clarté, revérifiez tous les champs présent dans l’onglet Body :

Vérifiez également l’onglet Headers, puis cliquez sur Envoyer :

Constatez le succès de l’opération via le message suivant :

L’étape suivante consiste maintenant à récupérer un accès token et refresh token afin de pouvoir utiliser le proxy HTTP Tesla dans Energyboard.

Etape VI – Génération d’un refresh token :

Pour cela, nous allons utiliser une autre application temporaire afin de capter facilement ces tokens. Rendez-vous sur la page GitHub suivante, puis lancez le téléchargement de l’archive ZIP :

Extrayez le contenu de l’archive ZIP dans le dossier de votre choix :

Ouvrez un onglet Windows PowerShell, positionnez-vous dans le dossier d’archive ci-dessous, puis lancez la commande suivante pour télécharger et installer toutes les dépendances répertoriées dans le fichier package.json du projet :

pnpm install

Créez un nouveau fichier .env à la racine de ce même dossier en y indiquant les deux informations présentes en gras :

TESLA_CLIENT_ID=VOTRE_ID_CLIENT
TESLA_CLIENT_SECRET=VOTRE_SECRET
TESLA_REFRESH_TOKEN=

Cela donne le fichier .env suivant :

Lancez la commande suivante afin de démarrer l’application de captage des tokens :

pnpm get-token

Copiez l’URL donnée par l’application lancée, puis ouvrez un navigateur internet :

Authentifiez-vous cette fois avec le compte propriétaire de la Tesla, cochez les cases suivantes, puis cliquez sur Autoriser :

Le navigateur affiche alors l’URL de callback créée par l’application lancée :

Un email de confirmation vous indique l’ajout de droits API à votre application :

Retournez sur l’application lancée sous Windows PowerShell afin de récupérer le refresh token capté :

Toutes les étapes se passent bien, testons maintenant que le rafraîchissement des tokens se déroule sans souci.

Etape VII – Test du rafraîchissement des tokens :

Retournez sur Insomnia afin d’effectuer un clique droit afin d’importer une nouvelle requête API :

curl --request POST \
  --url https://fleet-auth.prd.vn.cloud.tesla.com/oauth2/v3/token \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data grant_type=refresh_token \
  --data client_id=YOUR_CLIENT_ID \
  --data refresh_token=EU_XXX

Cette commande effectue une requête HTTP POST vers l’API de la flotte de Tesla afin d’enregistrer ou de créer un compte partenaire avec un domaine spécifique. Cela doit donner :

Nommez votre requête API pour plus de clarté, revérifiez tous les champs présent dans l’onglet Body, puis cliquez sur Envoyer :

Constatez le succès de l’opération via le message suivant :

L’enregistrement de l’application est maintenant terminée ! Il ne nous reste qu’à ajouter la clef virtuelle API sur notre Tesla.

Etape VIII – Enregistrement de la clef publique API sur la Tesla :

Pour cela, ouvrez la page suivante dans votre navigateur internet en remplaçant la valeur en gras par votre domaine Ngrok approuvé par Tesla :

https://tesla.com/_ak/YOUR_NGROK_DOMAIN

Depuis votre smartphone dans lequel installée l’application Tesla et agit déjà comme une clef de votre Tesla, scanner le QR en bas de votre page web :

L’application Tesla s’ouvre alors et vous demande d’autoriser l’application à votre véhicule, cliquez sur Approuver :

Un message d’opération réussie doit alors apparaître :

Votre Tesla est maintenant prête à recevoir des ordres via API. Il ne nous reste qu’à configurer Energyboard pour activer cette fonction.

Etape IX – Configuration API pour Energyboard :

Renseignez les informations suivantes pour qu’Energyboard exploite le service de communication API avec la voiture Tesla :

Pensez à sauvegarder le fichier de configuration via la commande suivante :

:wq

Arrêter l’application Energyboard :

pm2 stop energyboard

Démarrer l’application Energyboard :

pm2 start energyboard

Conclusion

En conclusion, cette dernière étape d’enrôlement de la Fleet API Tesla clôt un parcours riche en découvertes et en défis techniques : de la configuration de Ngrok à la génération des tokens, en passant par l’exposition de votre clef publique et l’inscription de votre application, chaque phase a consolidé votre compréhension des protocoles OAuth2 et des bonnes pratiques de sécurité.

Grâce à ce processus, vous bénéficiez désormais d’une connexion API robuste, entièrement maîtrisée, qui permet à votre tableau de bord domotique de communiquer en toute confiance avec votre Tesla.

N’hésitez pas à revisiter chaque étape si besoin, et gardez à l’esprit que cet investissement initial ouvre la voie à de nombreuses automatisations avancées et à un suivi précis de vos usages énergétiques.

Félicitations pour votre persévérance et bon pilotage !

Création de la connexion BLE Tesla

Le principe de la connexion BLE (Bluetooth Low Energy) repose sur l’établissement d’un canal de communication local, sécurisé et à faible consommation, permettant à un appareil externe (souvent via un outil ou une application personnalisée) d’envoyer des commandes directement au véhicule. Cette approche est idéale entre un véhicule Tesla et l’application EnergyBoard.

Voici les points essentiels à utiliser la liaison BLE sur un véhicule Tesla :

  1. Communication à courte portée et faible consommation
    Le BLE est conçu pour des échanges de données sur de courtes distances, ce qui est idéal pour communiquer avec un véhicule à proximité (par exemple, lors de l’utilisation d’un smartphone ou d’un dispositif embarqué).
  2. Découverte des services et appariement
    Le véhicule expose des services BLE spécifiques. L’outil (comme celui proposé dans le dépôt vehicle-command) scanne ces services et procède à un appariement ou à une authentification. Pour garantir la sécurité, cette phase d’appariement repose souvent sur l’échange de clés cryptographiques.
  3. Authentification par échange de clés
    Afin de s’assurer que seules les requêtes authentifiées parviennent au véhicule, le mécanisme implique l’utilisation d’une paire de clés publique/privée. Par exemple, la commande tesla-control -vin YOUR_VIN -ble -key-file BLE-private.pem wake illustre comment une clé privée est utilisée pour signer ou authentifier une commande envoyée via BLE. Ce processus assure que seul un utilisateur autorisé peut exécuter des commandes sensibles (comme le réveil du véhicule, le verrouillage ou le démarrage de la charge).
  4. Exécution des commandes
    Une fois la connexion établie et l’authentification réussie, l’appareil externe peut envoyer des commandes spécifiques (par exemple, pour réveiller le véhicule, obtenir son état, verrouiller/déverrouiller, etc.). Ces commandes sont interprétées par le système du véhicule et traduites en actions réelles.
  5. Sécurité et contrôle
    L’utilisation du BLE dans ce contexte permet de limiter la portée de la communication et d’exploiter un protocole conçu pour être économe en énergie. De plus, la sécurisation par clé cryptographique protège contre toute tentative d’intrusion non autorisée.

En résumé, la connexion BLE sur une Tesla, telle qu’illustrée dans le projet vehicle-command, consiste à établir un lien local entre un appareil et le véhicule, authentifier cette communication via un échange de clés, puis permettre l’envoi de commandes sécurisées pour contrôler diverses fonctions du véhicule.

Ce mécanisme offre un moyen efficace et sûr de gérer certaines opérations du véhicule sans passer par les serveurs Tesla.

Quelles sont les différentes étapes pour faire fonctionner BLE ?

Voici la liste des étapes que nous allons faire ensemble :

Etape 0 – Rappel des prérequis :

Pour mettre en place la connexion BLE à votre environnement Raspberry Pi 5, il vous faudra disposer de :

  • Un Raspberry Pi 5
  • Un accès SSH à votre environnement

Commençons par récupérer le programme officiel Tesla pour le protocole BLE, et développé en Go.

Etape I – Mise à jour de Go :

Téléchargez l’archive de Go version 1.23.0 pour Raspberry Pi 5 (ARM) :

wget https://go.dev/dl/go1.23.0.linux-arm64.tar.gz

Décompressez l’archive Go téléchargée dans le répertoire /usr/local :

sudo tar -C /usr/local -xzf go1.23.*.gz

Ouvrez le fichier de configuration Bash à l’aide de l’éditeur de texte en mode terminal Vi :

vi ~/.bashrc

Descendez en bas du fichier, puis ajoutez la ligne suivante grâce à la touche i :

export PATH=$PATH:/usr/local/go/bin

Enregistrez et quitter l’éditeur vi grâce à la commande suivante :

:wq

Forcez le rechargement du fichier de configuration Bash :

source ~/.bashrc

Affichez la version de Go actuellement installée :

go version

Etape II – Installation de vehicle-command :

Créez un nouveau répertoire nommé tesla dans le répertoire courant, puis déplacez-vous :

mkdir tesla
cd tesla

Clonez le dépôt GitHub du projet vehicle-command de Tesla dans un répertoire nommé vehicle-command dans le répertoire courant :

git clone https://github.com/teslamotors/vehicle-command.git
cd vehicle-command

Téléchargez l’ensemble des dépendances requises :

go get ./...

Compilez l’ensemble des package :

go build ./...

Installez l’ensemble des packages :

go install ./...

Exécutez la commande suivante pour vérifier le bon lancement du programme :

tesla-control -h

Etape III – Création de la clef virtuelle BLE :

Remontez dans le répertoire parent, créez un dossier nommé secrets, puis accédez -y :

cd ..
mkdir secrets
cd secrets/

Utilisez OpenSSL pour générer une clé privée EC à l’aide de la courbe prime256v1 :

openssl ecparam -genkey -name prime256v1 -noout > BLE-private.pem
openssl ec -in BLE-private.pem -pubout > BLE-public.pem

Attribuez à l’exécutable tesla-control la capacité réseau d’administration :

sudo setcap 'cap_net_admin=eip' "$(which tesla-control)"

Exécutez tesla-control en mode Bluetooth pour le véhicule identifié par le VIN afin de lancer la commande add-key-request en utilisant le fichier BLE-public.pem pour envoyer une requête d’ajout de clé associée à l’identité ou au rôle « owner » et à la clé identifiée par cloud_key :

tesla-control -vin YOUR_VIN -ble add-key-request BLE-public.pem owner cloud_key

Confirmez l’action d’association en couchant la carte NFC Tesla sur la console centrale de la voiture.

Etape IV – Test de la clef virtuelle BLE :

Pour tester le bon fonctionnement d’un ordre à la voiture, envoyez la commande de réveil au véhicule, en utilisant le fichier BLE-private.pem pour l’authentification.

tesla-control -vin YOUR_VIN -ble -key-file BLE-private.pem wake

L’absence de retour de la part de l’application équivaut à un succès de l’opération :

Dans votre navigateur internet, accédez à l’adresse http://ADRESSE_IP:4000 afin de constater une actualisation du statut de la voiture réveillée :

Testez au besoin d’autres commandes sur la Tesla parmi les commandes disponibles :

add-keyAdd PUBLIC_KEY to vehicle whitelist with ROLE and FORM_FACTOR
add-key-requestRequest NFC-card approval for a enrolling PUBLIC_KEY with ROLE and FORM_FACTOR
auto-seat-and-climateTurn on automatic seat heating and HVAC
autosecure-modelxClose falcon-wing doors and lock vehicle. Model X only.
body-controller-stateFetch limited vehicle state information. Works over BLE when infotainment is asleep.
charge-port-closeClose charge port
charge-port-open Open charge port
charging-scheduleSchedule charging to MINS minutes after midnight and enable daily scheduling
charging-schedule-addSchedule charge for DAYS START_TIME-END_TIME at LATITUDE LONGITUDE. The END_TIME may be on the following day.
charging-schedule-cancel Cancel scheduled charge start
charging-schedule-remove Removes charging schedule of TYPE [ID]
charging-set-ampsSet charge current to AMPS
charging-set-limit Set charge limit to PERCENT
charging-start Start charging
charging-stopStop charging
climate-offTurn off climate control
climate-on Turn on climate control
climate-set-temp Set temperature (Celsius)
driveRemote start vehicle
erase-guest-data Erase Guest Mode user data
flash-lights Flash lights
frunk-open Open vehicle frunk. Note that there's no frunk-close command!
getGET an owner API http ENDPOINT. Hostname will be taken from -config.
guest-mode-off Disable Guest Mode.
guest-mode-onEnable Guest Mode. 
honk Honk horn
list-keysList public keys enrolled on vehicle
lock Lock vehicle
media-set-volume Set volume
media-toggle-playbackToggle between play/pause
ping Ping vehicle
post POST to ENDPOINT the contents of FILE. Hostname will be taken from -config.
precondition-schedule-addSchedule precondition for DAYS TIME at LATITUDE LONGITUDE.
precondition-schedule-remove Removes precondition schedule of TYPE [ID]
product-info Print JSON product info
remove-key Remove PUBLIC_KEY from vehicle whitelist
rename-key Change the human-readable metadata of PUBLIC_KEY to NAME, MODEL, KIND
seat-heaterSet seat heater at POSITION to LEVEL
sentry-modeSet sentry mode to STATE ('on' or 'off')
session-info Retrieve session info for PUBLIC_KEY from DOMAIN
software-update-cancel Cancel a pending software update
software-update-startStart software update after DELAY
stateFetch vehicle state over BLE.
steering-wheel-heaterSet steering wheel mode to STATE ('on' or 'off')
tonneau-closeClose Cybertruck tonneau.
tonneau-open Open Cybertruck tonneau.
tonneau-stop Stop moving Cybertruck tonneau.
trunk-closeCloses vehicle trunk. Only available on certain vehicle types.
trunk-move Toggle trunk open/closed. Closing is only available on certain vehicle types.
trunk-open Open vehicle trunk. Note that trunk-close only works on certain vehicle types.
unlock Unlock vehicle
valet-mode-off Disable valet mode
valet-mode-onEnable valet mode
wake Wake up vehicle
windows-closeClose all windows
windows-vent Vent all windows

Testez au besoin d’autres commandes sur votre Tesla via BLE :

Votre Tesla est maintenant prête à recevoir des ordres via BLE. Il ne nous reste qu’à configurer EnergyBoard pour activer cette fonction.

Etape V – Configuration BLE pour EnergyBoard :

Renseignez les informations suivantes pour qu’EnergyBoard exploite le service de communication BLE avec la voiture Tesla :

Pensez à sauvegarder le fichier de configuration via la commande suivante :

:wq

Arrêter l’application EnergyBoard :

pm2 stop energyboard

Démarrer l’application EnergyBoard :

pm2 start energyboard

La connexion Bluetooth entre EnergyBoard et la Tesla est maintenant fonctionnelle. Si vous le souhaitez, vous pouvez passer à l’étape facultative suivante, consistant à configurer le lien API entre EnergyBoard et le serveurs Tesla. Ce dernier va nous permettre de :

  • Envoyer des ordres Tesla via API grâce au conteneur Proxy HTTP quand la liaison Bluetooth n’est pas disponible.

Etape suivante : Création de la connexion API Tesla

Installation de Teslamate

Installer Teslamate se fait en quelques commandes simples, à l’image d’un projet DIY accessible à tous. Teslamate, un datalogger open-source, récupère en local les données de votre Tesla (trajets, consommations, charge…) et les présente via une interface web riche en graphiques et statistiques.

L’ensemble tourne sur Docker, ce qui évite d’installer manuellement chaque composant, et reste sécurisé tant qu’il n’est pas exposé à l’extérieur par défaut. Le mode opératoire décrit ci-dessous est inspiré de celui déjà disponible à cette adresse.

Etape 0 – Rappel des prérequis :

Pour installer Teslamate sur votre environnement (machine virtuelle Azure ou Raspberry Pi 5), il vous faudra disposer de :

  • Une machine virtuelle Azure ou Raspberry Pi 5
  • Un accès SSH à votre environnement

Avant d’installer Teslamate, commençons par mettre à jour notre environnement.

Etape I – Mise à jour de l’environnement :

Une fois connecté en SSH à votre environnement (Azure ou Raspberry Pi 5), effectuez les commandes suivantes, une par une, afin de préparer ce dernier

Téléchargez et exécutez automatiquement le script d’installation de Docker depuis le site officiel :

curl -sSL https://get.docker.com | sh

Ajoutez l’utilisateur spécifié au groupe « docker » pour permettre l’exécution des commandes Docker sans utiliser sudo :

sudo usermod -aG docker VOTRE_NOM_UTILISATEUR

Rechargez les paramètres de groupe de l’utilisateur dans la session en cours afin d’appliquer la nouvelle appartenance au groupe « docker » :

newgrp docker

Lancez un conteneur de test (hello-world) pour vérifier que Docker est correctement installé et opérationnel :

docker run hello-world

Installez les bibliothèques de développement libffi et libssl, nécessaires pour certaines compilations et dépendances, notamment pour des outils Python :

sudo apt-get install -y libffi-dev libssl-dev

Installez Python 3 ainsi que pip, le gestionnaire de paquets pour Python 3 :

sudo apt-get install -y python3 python3-pip

Désinstallez le paquet python-configparser, souvent redondant ou source de conflits avec la version intégrée dans Python 3 :

sudo apt-get remove python-configparser

Etape II – Installation de Teslamate :

Créez un nouveau répertoire nommé teslamate dans le répertoire courant, puis déplacez-vous dans celui-ci :

mkdir teslamate
cd teslamate/

Créez le fichier docker-compose.yml depuis l’éditeur de texte vi pour permettre son édition :

vi docker-compose.yml

Dans l’éditeur de texte vi, appuyez sur la touche i pour passer en mode édition, puis collez le manifeste ci-dessous. Avant de le copier, pensez à modifier les secrets suivants :

  • Secretkey de ENCRYPTION_KEY par 12 caractères ou plus, pour sécuriser votre connexion. Utilisez si besoin Key Generator.
  • Mot de passe de DATABASE_PASS (à 3 endroits) par le mot de passe de votre choix.
version: "3.8"

services:
  teslamate:
    image: teslamate/teslamate:latest
    restart: always
    environment:
      - ENCRYPTION_KEY=secretkey #replace with a secure key to encrypt your Tesla API tokens
      - DATABASE_USER=teslamate
      - DATABASE_PASS=#insert your secure database password!
      - DATABASE_NAME=teslamate
      - DATABASE_HOST=database
      - MQTT_HOST=mosquitto
    ports:
      - "4000:4000"
    volumes:
      - ./import:/opt/app/import
    cap_drop:
      - all

  tesla_http_proxy:
    image: tesla/vehicle-command:latest
    restart: always
    ports:
      - "4443:4443"
    environment:
      - TESLA_HTTP_PROXY_TLS_CERT=/config/tls-cert.pem
      - TESLA_HTTP_PROXY_TLS_KEY=/config/tls-key.pem
      - TESLA_HTTP_PROXY_HOST=0.0.0.0
      - TESLA_HTTP_PROXY_PORT=4443
      - TESLA_HTTP_PROXY_TIMEOUT=10s
      - TESLA_KEY_FILE=/config/fleet-key.pem
      - TESLA_VERBOSE=true
    volumes:
      - ./tesla_http_proxy/config:/config

  database:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_USER=teslamate
      - POSTGRES_PASSWORD=#insert your secure database password!
      - POSTGRES_DB=teslamate
    volumes:
      - teslamate-db:/var/lib/postgresql/data

  grafana:
    image: teslamate/grafana:latest
    restart: always
    environment:
      - DATABASE_USER=teslamate
      - DATABASE_PASS=#insert your secure database password!
      - DATABASE_NAME=teslamate
      - DATABASE_HOST=database
    ports:
      - "3000:3000"
    volumes:
      - teslamate-grafana-data:/var/lib/grafana

  mosquitto:
    image: eclipse-mosquitto:2
    restart: always
    command: mosquitto -c /mosquitto-no-auth.conf
    ports:
      - "1883:1883"
    volumes:
      - mosquitto-conf:/mosquitto/config
      - mosquitto-data:/mosquitto/data

volumes:
  teslamate-db:
  teslamate-grafana-data:
  mosquitto-conf:
  mosquitto-data:

Une fois le manifeste collé, appuyez sur Echap pour quitter le mot édition de vi, puis sauvegardez votre fichier avec la commande suivante, suivie de la touche Entrée :

:wq

Etape III – Création de certificats pour Tesla Proxy :

Sous le dossier teslamate, créez arborescence suivante, puis déplacez-vous-y :

mkdir ./tesla_http_proxy
mkdir ./tesla_http_proxy/config
cd tesla_http_proxy/config/

Créez un certificat auto-signé à l’aide d’OpenSSL :

openssl req -x509 -nodes -newkey ec \
    -pkeyopt ec_paramgen_curve:secp521r1 \
    -pkeyopt ec_param_enc:named_curve  \
    -subj '/CN=localhost' \
    -keyout tls-key.pem -out tls-cert.pem -sha256 -days 3650 \
    -addext "extendedKeyUsage = serverAuth" \
    -addext "keyUsage = digitalSignature, keyCertSign, keyAgreement"

Modifiez les permissions des fichiers PEM pour que le propriétaire et le groupe puissent le lire et l’écrire (6), tandis que les autres utilisateurs n’ont qu’un droit de lecture (4) :

sudo chmod 664 *.pem

Générez une clé privée, avec sa clef publique, pour assurer une authentification des commandes via API émises vers la Tesla :

openssl ecparam -name prime256v1 -genkey -noout -out fleet-key.pem
openssl ec -in fleet-key.pem -pubout -out com.tesla.3p.public-key.pem

Etape IV – Démarrage des conteneurs Docker

Depuis le dossier teslamate, démarrez en mode détaché (en arrière-plan) tous les services définis dans le fichier docker-compose.yml :

docker compose up -d

Docker commence par télécharger toutes les images nécessaires aux services définis dans votre fichier docker-compose.yml, afin de s’assurer qu’elles soient disponibles localement pour créer et démarrer les conteneurs :

Attendez et vérifiez le bon démarrage de tous les conteneurs :

Ouvrez le fichier de configuration du service Systemd, nommé teslamate.service, dans l’éditeur de texte vi avec des privilèges administrateur afin de définir comment lancer, arrêter et gérer le service Teslamate.

sudo vi /etc/systemd/system/teslamate.service

En mode édition, collez le code suivant afin d’automatiser la gestion de Teslamate en s’assurant que Docker est prêt avant de lancer l’ensemble des conteneurs en cas de problème, en n’oubliant pas de modifier USER par votre nom d’utilisateur :

[Unit]
Description=TeslaMate Docker Compose Service
Requires=docker.service
After=docker.service

[Service]
WorkingDirectory=/home/USER/teslamate
ExecStart=/usr/local/bin/docker compose up -d
ExecStop=/usr/local/bin/docker compose down
Restart=always
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Appuyez sur Echap pour quitter le mot édition, puis sauvegardez votre fichier avec la commande suivante, suivie de la touche Entrée :

:wq

Demandez à systemd de recharger tous ses fichiers de configuration :

sudo systemctl daemon-reload

Configurez systemd pour démarrer automatiquement le service Teslamate au prochain démarrage du système, en créant les liens symboliques nécessaires dans les répertoires d’unités.

sudo systemctl enable teslamate.service

Démarrez et affichez l’état actuel du service Teslamate :

sudo systemctl start teslamate.service
sudo systemctl status teslamate.service

Listez l’ensemble des conteneurs Docker qui sont actuellement en cours d’exécution, en affichant des informations telles que l’ID du conteneur, l’image utilisée, l’état, les ports exposés et le nom du conteneur :

docker ps

Etape V – Configuration de Teslamate :

Dans votre navigateur internet, accédez à l’adresse http://ADRESSE_IP:4000 :

Pour générer les tokens, utilisez un outil comme tesla_auth, téléchargeable sur GitHub :

Lancez l’exécutable tesla_auth.exe, puis authentifiez-vous avec votre compte Tesla :

Entre le code de votre méthode 2FA, si cette dernière est configurée :

Copiez les deux tokens affichés dans l’application tesla_auth :

  • Les access tokens servent à authentifier et autoriser directement l’accès aux API et ressources protégées (et sont généralement de courte durée).
  • Les refresh tokens permettent d’obtenir de nouveaux access tokens lorsque ceux-ci expirent, assurant ainsi une continuité de session sans nécessiter une réauthentification manuelle.

Collez dans Teslamate les 2 tokens, puis cliquez-ici pour vous authentifier :

Si l’accès est confirmé, Teslamate devrait alors vous afficher la ou les voitures Tesla rattachées à votre compte Tesla :

Bonus : accédez à votre tableau de bord Teslamate via l’adresse http://ADRESSE_IP:3000, dont les identifiants par défaut sont admin/admin :

Une fois connecté pour la première fois, personnalisez le mot de passe de votre compte admin :

Une grande quantité de tableaux de bord y sont disponibles :

Teslamate est maintenant installé, vous pouvez passer à l’étape suivante, consistant à installer et configurer EnergyBoard. Ce dernier va nous permettre de :

  • Remonter les informations liées à la production solaire Enphase
  • Remonter les informations liées à la charge Tesla
  • Envoyer des ordres Tesla via BLE grâce l’application Tesla-control
  • Envoyer des ordres Tesla via API grâce au conteneur Tesla Proxy HTTP

Etape suivante : Installation d’EnergyBoard

Alternative : EnergyBoard sur une machine virtuelle Azure

Installer EnergyBoard sur une machine virtuelle Azure présente plusieurs atouts : vous vous affranchissez des contraintes liées à un serveur dédié ou à un Raspberry Pi, et bénéficiez de la scalabilité et de la haute disponibilité du cloud. En contrepartie, le pilotage Bluetooth local n’est pas possible depuis Azure, ce qui vous limite aux seuls appels API Tesla pour la gestion du véhicule.

Cette architecture cloud peut toutefois s’avérer très intéressante pour centraliser votre dashboard et automatiser les mises à jour, à condition de prévoir l’ouverture des ports nécessaires (HTTP/8002, TCP…) afin de relayer les requêtes vers votre passerelle Enphase, qui elle reste sur votre réseau domestique.

Etape 0 – Rappel des prérequis :

Pour installer votre application EnergyBoard sur Azure, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Commençons par créer la machine virtuelle Linux.

Etape I – Création de la machine virtuelle Linux :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle de petite puissance :

Renseignez les informations d’administration, puis cliquez sur Suivant :

Adaptez la performance du disque, puis cliquez sur Suivant :

Conservez les options réseaux, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle :


Ensuite, cliquez-ici pour déployer une règle entrante de réseau :

Ajoutez la configuration suivante pour autoriser les connexions depuis votre adresse IP publique, visible sur cette page, puis cliquez sur Ajouter :

Retournez sur la page principale de votre machine virtuelle afin de copier l’adresse IP publique de celle-ci :

Depuis votre ordinateur, ouvrez Windows PowerShell :

Connectez-vous en SSH à votre machine virtuelle Azure via son adresse IP publique précédemment copiée :

ssh VOTRE_NOM_UTILISATEUR@ADRESSE_IP_PUBLIQUE

Une fois connecté à votre machine virtuelle Azure, vous pouvez passer à l’étape suivante, consistant à installer et déployer Teslamate. Ce dernier va nous permettre de :

  • Stocker les données MQTT émises par la voiture Tesla
  • Consulter les données MQTT depuis EnergyBoard
  • Envoyer des ordres API via l’agent Proxy HTTP (facultatif)

Etape suivante : Installation de Teslamate