Logiciel pour
l'énergie, la mobilité et les médias
Nous travaillons dans quatre domaines où les données sont en temps réel, les protocoles sont industriels et une lecture erronée entraîne des conséquences opérationnelles. Choisissez le domaine le plus proche de votre problème — chaque page décrit ce que nous construisons et la pile technique.
Où nous allons en profondeur
Une équipe déjà maîtresse des protocoles, des modes de défaillance et du vocabulaire opérateur d'un secteur ne facture pas cet apprentissage au client. Le travail commence au niveau de l'intégration, pas des fondamentaux.
Logiciel de portefeuille solaire→
Monitoring de portefeuille pour les opérateurs PV : télémétrie d'onduleur en direct, ratio de performance corrigé par l'ensoleillement, rapports de rendement et alertes basées sur des règles pour plusieurs sites.
Gestion et monitoring BESS→
Vues de salle de contrôle sur les blocs de batteries, les onduleurs PV et les strings DC : flux d'énergie en direct, analytique SOC/SOH, diagnostic au niveau des strings et alarmes basées sur des règles.
Plateformes de recharge EV→
Backends CPO et EMSP, gestion de recharge en marque blanche, recharge intelligente et équilibrage de charge, ainsi que la planification d'itinéraires pour les flottes EV commerciales multi-arrêts.
Infrastructure vidéo→
Pipelines de transcodage et d'empaquetage : échelles ABR, encodage par titre, HLS à faible latence, livraison Multi-DRM et encodage accéléré par matériel à grande échelle.
Les équipes généralistes apprennent le domaine à vos frais
La majeure partie des coûts dans un projet logiciel industriel ne se trouve pas dans le code — elle réside dans les malentendus. Une équipe qui n'a jamais lu le modèle de données IEC 61850 ou qui traite une session OCPP comme un simple échange requête/réponse, découvre les vraies exigences lors des tests d'intégration. C'est l'endroit le plus coûteux pour les découvrir.
Travailler dans un nombre limité de domaines nous permet de partir des contraintes plutôt que d'un framework. Nous savons quels champs de télémétrie sont peu fiables en pratique, quelles implémentations de fournisseurs s'écartent de la spécification et quels indicateurs un opérateur regarde en premier.
- Comportement des protocoles connu en amont, pas découvert lors de l'intégration
- Modèles de données conçus pour les schémas de requêtes réels, pas pour du CRUD générique
- Interfaces évaluées selon la façon dont les opérateurs travaillent, pas selon les démos
- Modes de défaillance et cas limites nommés lors de la phase d'architecture, pas après le démarrage
- Estimations fondées sur la réalité du domaine plutôt que sur des analogies optimistes
Ce qui est commun aux quatre domaines
Les domaines diffèrent ; le socle d'ingénierie, non. Chaque plateforme que nous construisons repose sur les mêmes trois couches.
Ingestion de télémétrie
Adaptateurs de protocoles, ingestion par broker et par polling, pipelines d'enrichissement et stockage de séries temporelles dimensionné pour les schémas de requêtes réels des opérateurs.
Interfaces de niveau opérateur
Tableaux de bord React en temps réel pour les personnes prenant des décisions sous contrainte de temps — hiérarchie d'information d'abord, bibliothèque de graphiques ensuite.
Opérations de production
Journalisation structurée, traçage distribué, alerting et pipelines CI/CD dès le premier commit, afin que le système reste maintenable après la livraison.
Vous ne savez pas quelle section correspond à votre projet ?
Décrivez le matériel, les protocoles et les utilisateurs. Nous vous dirons ce qui est simple, ce qui présente des risques et où nous l'avons déjà fait.