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 mois, 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 😎

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

EnergyBoard sur Raspberry Pi 5

Installer EnergyBoard sur un Raspberry Pi 5 offre l’avantage d’un serveur compact, économe en énergie et directement relié à votre installation 100% locale : vous avez accès nativement au Bluetooth local pour piloter votre Tesla et la passerelle Enphase sans passer par le cloud. Cette approche vous garantit une réactivité maximale et un contrôle complet de votre infrastructure.

Pour écrire cet article, j’ai donc acheté ce kit de démarrage Raspberry Pi 5 de 8Go, dont il en existe beaucoup sur internet :

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 l’application EnergyBoard sur votre Raspberry Pi 5, il vous faudra disposer de :

  • Un Raspberry Pi 5
  • Un poste local connecté en réseau au Raspberry Pi 5
  • Une connexion internet
  • une carte Micro-SD (dans le kit Raspberry Pi 5 acheté était fournie une carte Micro-SD de 64 Go avec un adaptateur USB-A/C)

Commençons par préparer l’OS du Raspberry Pi 5 à l’aide de notre poste local.

Etape I – Préparation de l’OS du Raspberry Pi 5 :

Branchez l’adaptateur contenant la carte Micro-D sur un port USB-A/C de votre poste local.

Sur votre poste, téléchargez le gestionnaire d’image OS pour Raspberry Pi depuis la page officielle :

Lancez l’exécutable téléchargé afin de l’installer l’outil de gestion d’image OS sur votre poste :

Une fois l’outil Raspberry Pi Image installé, lancez celui-ci, renseignez les 3 informations comme ceci, puis cliquez sur Suivant :

Cliquez sur le bouton suivant afin de personnaliser quelques réglages :

Sur le premier onglet, définissez le compte administrateur de votre choix, et si besoin la configuration wifi à utiliser :

Sur le second onglet, autorisez l’accès SSH (protocole qui permet d’établir une connexion chiffrée pour accéder et administrer un système à distance), puis cliquez sur Sauvegarder :

Cliquez cette fois sur Oui :

Confirmez l’écrasement des données en cliquant sur Oui :

Le traitement d’écriture sur la carte Micro-SD commence alors :

Attendez la fin des phases d’écriture et de vérification de la carte Micro-SD :

Une fois le processus terminé, retirer la carte Micro-SD, puis cliquez sur Continuez :

Insérer la carte Micro-SD dans votre Raspberry Pi 5, puis démarrez ce dernier.

En fonction de votre moyen de connexion de votre Raspberry Pi 5, ce dernier devrait disposer d’une adresse IP locale attribuée automatiquement par votre box (cette information est à vérifier et à obtenir sur la page de configuration réseau de votre box internet) :

Depuis votre ordinateur, ouvrez Windows PowerShell :

Connectez-vous en SSH à votre Raspberry Pi 5 via son adresse IP locale :

ssh VOTRE_NOM_UTILISATEUR@ADRESSE_IP_LOCALE

Une fois connecté à votre Raspberry Pi 5, 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

Mon expérience GitHub Copilot

Comment exploiter GitHub Copilot pour améliorer sa pratique du code et élargir ses compétences, même sans être un expert ? Voir peut-on utiliser GitHub Copilot même si on n’est pas développeur du tout ? Pour ma part en tant que néophyte du dev, j’ai découvert qu’en posant les bonnes questions et en affinant peu à peu mes demandes, GitHub Copilot devient un véritable partenaire de réflexion dans le développement.

Ces dernières années nous ont appris que le dialogue constant avec l’IA permet de résoudre des problèmes concrets plus rapidement, tout en apprenant de nouvelles notions. Le potentiel est immense : c’est un formidable tremplin pour repousser ses limites et explorer de nouveaux horizons.

Pour ma part, je ne suis pas développeur de métier, et pour autant, j’ai toujours eu envie d’optimiser le rendement de mon installation photovoltaïque. Ayant des panneaux solaires depuis déjà plusieurs années, il était plus que temps pour moi de revoir mon taux très bas d’indépendance énergétique :

Qu’est-ce que le taux indépendance énergétique ?

Le taux d’indépendance énergétique est un indicateur qui mesure la part de votre consommation électrique totale couverte par votre propre production photovoltaïque, sans recours au réseau .

Concrètement, on le calcule ainsi :

  • Autoconsommation = part de votre production solaire que vous consommez directement
  • Indépendance énergétique = part de votre consommation qui vient de votre propre production

Exemple : si vous consommez 30 kWh sur une journée et que vous avez utilisé 20 kWh de votre production solaire, alors votre taux d’indépendance est de 66,7%.

Comment améliorer son taux d’indépendance énergétique ?

Voici plusieurs leviers pour augmenter un taux d’indépendance énergétique :

Stocker l’énergie

  • Installer une batterie domestique pour conserver le surplus de production et l’utiliser en soirée ou la nuit.
  • Piloter la recharge de votre véhicule électrique.
  • Utiliser un chauffe-eau ou un chauffe-eau thermodynamique asservi au surplus photovoltaïque.

Réduire et optimiser votre consommation

  • Améliorer l’isolation (toit, murs, fenêtres) pour limiter le besoin de chauffage et de climatisation.
  • Remplacer les équipements par des modèles à haute efficacité (LED, électroménager classé A+++).
  • Débrancher les veilleuses et appareils en veille qui continuent de consommer.

Déplacer les usages vers les heures de production

  • Programmer les gros consommateurs (lave-linge, lave-vaisselle, machine à café) en pleine journée.
  • Piloter intelligemment les consommateurs.

Qu’est-ce que EnergyBoard ?

EnergyBoard est une application web open-source développée à l’origine par Zzzzz avec le soutien de Mathieu3878 pour le code et de SolarFan pour la documentation et la traduction.

Elle a pour but de compléter et d’améliorer l’application officielle d’Enphase, Enlighten. Cette application :

  • Affiche en temps réel la production photovoltaïque, la consommation du foyer, ainsi que l’énergie importée ou exportée ,
  • Propose des animations de flux, des courbes d’historique (2 s, 1 min, jour, mois, année) et un calendrier annuel,
  • Fournit des analyses avancées (météo annuelle de production, taux d’indépendance énergétique, taux d’autoconsommation) ,
  • Permet de piloter la charge d’une Tesla selon le surplus solaire ou des modes programmables.

En résumé, EnergyBoard transforme votre installation PV en dashboard intelligent, pour maximiser l’autoconsommation, visualiser vos données en live et automatiser vos recharges électriques. Voici quelques liens :

Tout fonctionnait parfaitement… jusqu’à ce que Tesla modifie son API…

Quel est le rapport avec GitHub Copilot ?

Comme Tesla avait modifié en 2024 le fonctionnement de ses API, EnergyBoard n’était plus en mesure de communiquer directement la voiture, et donc piloter la recharge dynamique.

Souhaitant réinstaurer le lien entre EnergyBoard et la voiture Tesla, et plutôt que de repartir de zéro, je me suis tourné vers l’intelligence artificielle : GitHub Copilot pour suggérer des bouts de code, et ChatGPT pour m’expliquer certaines notions, comme par exemple la gestion des tokens, la mise en place de proxys, l’orchestration de conteneurs et la sécurisation des secrets…

Grâce à à ces deux IAs, j’ai pu :

  • Interfacer la nouvelle Fleet API de Tesla et gérer les différents tokens.
  • Ajouter une couche de communication directe en Bluetooth entre l’application EnergyBoard et la voiture Tesla.
  • Gérer les retours de données de la Tesla provenant de 3 sources distinctes :
    • API (Serveurs Tesla + Voiture)
    • MQTT (Push Serveurs Tesla)
    • Bluetooth (Voiture)
  • Ajouter un journal événements précis concernant les actions Tesla déclenchées par l’application.
  • Ajouter d’autres interfaces avec des applications tierces :
  • Correctement configurer le Raspberry Pi.

L’intelligence artificielle m’a donc servi de copilote technique, accélérant ma montée en compétences sur l’authentification, la gestion des secrets et les patterns d’architecture, tout en me permettant de rester productif même sans être développeur expert.

Et maintenant ?

Suite aux retours et aux tests, dans la version 0.9.37, est introduit la prise en charge native des appels Bluetooth pour piloter la Tesla en local.

Cette approche est non seulement plus simple à configurer (plus besoin de relayer systématiquement toutes les requêtes via l’API Tesla cloud), mais elle permet aussi une mise en place et des temps de réponse beaucoup plus rapides dans un environnement réseau 100% local.

👉 Téléchargez la V 0.9.37 ici : http://didier.paradis.free.fr/energyboard

Et si l’on souhaite quand même communiquer par API ?

Si l’on souhaite aussi communiquer via l’API cloud, j’ai créé une version alternative d’EnergyBoard, capable de gérer à la fois les appels Bluetooth et les requêtes API. Le processus d’installation et d’enrôlement API est un peu complexe et nécessite du matériel adapté (clé Bluetooth, token Tesla, configuration réseau, etc.), mais tout est détaillé dans les articles ci-dessous, organisés en sections :

Chacun de ces articles vous guide pas à pas, du déploiement sur Raspberry Pi, ou sur une machine virtuelle Azure, ou jusqu’à la mise en service des connexions Bluetooth et API Tesla.

👉 Voici le lien pour télécharger cette version alternative.

Conclusion

J’ai pris un immense plaisir à explorer cette passerelle entre intelligence artificielle et code : passer de simples idées à une application à nouveau fonctionnelle m’a non seulement permis d’élargir mes compétences bien au-delà de mon profil « IT généraliste ».

Que vous soyez néophyte ou développeur aguerri, je vous encourage vivement à vous lancer : GitHub Copilot et ChatGPT sont des alliés formidables pour vous guider, vous faire gagner un temps précieux et vous aider à comprendre des concepts qui paraissent souvent abstraits.

Au-delà du projet EnergyBoard, ces outils nous offrent une véritable boîte à outils cognitive, capable de nous accompagner dans tous nos domaines de prédilection. Alors, pourquoi ne pas embarquer votre prochain challenge sous le bras et laisser l’IA vous copiloter vers l’innovation ?

Bon codage !