6. Travail concret : recharge électrique, sécurité et cloud
Repères : enregistrement 39:10–41:00 et 62:00–70:15.
6.1. AXSO : un système complet autour des bornes
Patrick décrit une activité de développement et de maintenance des technologies de recharge pour véhicules électriques. Le travail ne consiste pas seulement à écrire une application mobile : plusieurs catégories d’utilisateurs et plusieurs couches techniques doivent fonctionner ensemble.
| Composante | Fonction exposée dans la conférence |
|---|---|
| Applications mobiles | Services aux conducteurs et consommateurs. |
| Portails de gestion | Outils pour les opérateurs de réseaux et les agents de soutien. |
| Communications et infrastructure | Échanges avec les bornes, réception d’événements et exploitation des systèmes. |
| Gestion d’énergie et tarifs | Fonctions en temps réel et usages liés aux immeubles, à la recharge publique et à la recharge privée. |
| Données et opérations financières | Traitements associés à l’activité des réseaux et à leur exploitation. |
Le Circuit électrique, des réseaux en Colombie-Britannique et en Floride et des usages multilogements sont évoqués. Certains noms secondaires de réseaux sont mal reconnus et ne sont pas fabriqués ici. Les catégories d’activités, la portée géographique et le rôle des outils sont conservés.
Pour rendre l’échelle concrète, Patrick cite environ 520 millions d’événements de bornes ingérés chaque mois. Cela ne compte que l’entrée des événements, avant les réponses et autres traitements. Il évoque aussi un volume financier annuel de plusieurs millions : c’est une grandeur différente, et non le nombre annuel d’événements. Une question vers 62:00 reprend environ 600 000 clients. Ces chiffres viennent du témoignage daté, sans audit indépendant de l’entreprise.
La distinction entre ces grandeurs est essentielle : nombre de clients, nombre d’événements et volume financier décrivent des aspects différents de la charge et des responsabilités du système. Il ne faut ni les additionner ni transformer l’un en l’autre. Les exemples de gestion d’énergie en temps réel et de tarification montrent aussi que le logiciel doit répondre à un contexte métier précis, notamment les réseaux publics, privés et les immeubles. Patrick relie ces fonctions à la possibilité de tarifs préférentiels pour des condos, sans fournir de grille tarifaire : c’est un exemple de valeur métier de la gestion d’énergie, pas une offre ou un prix vérifié ici.
6.2. Sécurité : une équipe interne, des audits et un appui de groupe
AXSO est présentée comme liée à Hydro-Québec. Patrick souligne un appui pour certaines fonctions légales et administratives, permettant à son équipe de se concentrer sur son activité informatique. Sur la sécurité, il décrit des ressources propres de conformité et de cybersécurité, auxquelles s’ajoutent celles du groupe.
Le lien à Hydro-Québec apporte des ressources, mais également des exigences et audits additionnels. Patrick mentionne la conformité SOC 2 Type II, des audits propres internes et externes et les pratiques du groupe. Ce n’est donc pas simplement une externalisation de toute la sécurité : des responsabilités et compétences demeurent dans l’entreprise.
À la question sur les attaques, il ne rapporte pas de grande attaque dans son expérience de l’organisation, tout en rappelant qu’on n’est jamais à l’abri. Ce témoignage ne prouve ni l’absence absolue d’incident ni une immunité future. Le raisonnement pertinent est celui d’une défense entretenue, de contrôles et d’une répartition de responsabilités, pas d’une sécurité acquise une fois pour toutes.
6.3. AWS et le modèle de responsabilité partagée
Patrick indique qu’AXSO utilise AWS. Le modèle de responsabilité partagée définit ce qui relève du fournisseur et ce qui reste à la charge de l’organisation qui utilise le service. Déléguer une infrastructure ne signifie pas déléguer tout ce qui permet au logiciel de fonctionner correctement.
Dans son exemple, AWS prend en charge une partie de l’exploitation et des mises à jour de l’infrastructure; l’entreprise reste responsable de son code et de ses logiciels. Le fournisseur ne met pas automatiquement à jour une application développée par son client. Des personnes chargées de l’infrastructure travaillent encore chez AXSO : création de services, besoins de nouvelles fonctionnalités, mises à jour critiques et déploiements font partie des tâches évoquées.
Une précision de la documentation primaire AWS évite une généralisation : les tâches exactes dépendent du service choisi. Sur une instance où le client administre un système invité, ses mises à jour peuvent lui incomber; sur des services plus abstraits, le fournisseur assume davantage de couches. La conférence donne un cas de répartition, pas une dispense universelle d’entretien des systèmes hébergés dans le cloud.
Ce cas rejoint le message sur les métiers : une nouvelle technologie change les tâches, les outils et les interfaces de responsabilité, sans faire disparaître le besoin de compétences. Comprendre ce que l’on conserve à sa charge est une condition de l’exploitation et de la sécurité.