Portfolio d'apprentissage

J'ai pu acquérir cette compétence grâce à mon alternance chez Kuzzle, où j'ai conçu une plateforme IoT temps réel destinée à des clients industriels. Le choix d'architecture s'est fait en confrontant des contraintes concrètes : volumétrie élevée des capteurs LoRaWAN, besoin de visualisation à la milliseconde, multi-tenant. J'ai retenu Kuzzle comme backend pour exploiter son support natif des WebSockets et son indexation Elasticsearch (séries temporelles + recherche full-text), Vue.js côté frontend pour des composants de visualisation dynamiques (graphiques, jauges, alertes paramétrables), et Docker pour homogénéiser le déploiement entre dev et prod (CE1.06). Le co-développement du framework Sproogy m'a aussi obligé à raisonner architecture sous un autre angle : container IoC, injection de dépendances par annotations, pattern Controller–Service–Repository, analyse statique du graphe de dépendances pour détecter les cycles au démarrage. Ce double terrain — un produit prod chez Kuzzle, un framework chez moi — a aidé à comprendre qu'une bonne architecture n'est jamais un dogme : elle est le résultat d'un arbitrage entre besoins (CE1.01), contraintes techniques, et capacité de l'équipe à la maintenir dans la durée. Aujourd'hui je suis capable de justifier un choix archi avec des trade-offs explicites au lieu d'aller au plus rapide.

J'ai pu acquérir cette compétence grâce à mon stage de trois mois au CNRS (Pôle Protéome de Montpellier), où j'ai repris intégralement un outil scientifique historiquement écrit en Perl pour le porter en Python. Le code de départ était dense, peu lisible et accumulait des effets de bord — typique des scripts de recherche maintenus pendant des années sans refactor. J'ai dû d'abord lire et comprendre la logique métier (parsing de fichiers protéomiques volumineux), isoler les responsabilités, puis réécrire en modules Python clairs avec docstrings, nommage explicite et tests sur les cas pivots — tout en garantissant l'équivalence fonctionnelle (CE1.04). En parallèle, la plateforme Kuzzle évolue en continu : chaque sprint j'ajoute des fonctionnalités (nouveaux décodeurs LoRaWAN, nouveaux widgets dashboard) sans casser les flux existants — ce qui m'a appris à faire des évolutions non-régressives, à versionner les API, et à anticiper l'impact d'un changement sur les consommateurs. Cette double expérience — refactor brutal côté CNRS, évolution incrémentale côté Kuzzle — m'a donné un vrai recul sur la dette technique et sur le coût réel d'une feature au-delà du simple « ça compile ».

J'ai pu acquérir cette compétence grâce à l'alternance chez Kuzzle, où la plateforme IoT est déployée chez de vrais clients industriels : ce n'est plus du localhost, ce sont des serveurs avec des SLA, des logs, du monitoring, et des utilisateurs qui se plaignent quand ça tombe. J'interviens sur la chaîne complète : Dockerfiles, configuration des environnements (staging/prod), gestion des secrets, suivi des métriques. Ce contexte m'a forcé à comprendre la différence entre faire tourner un service localement et le livrer comme un produit qu'on supervise. En parallèle, mon homelab Proxmox me sert de bac à sable production-like : services auto-hébergés exposés publiquement (GitLab, reverse proxy HTTPS, bastion), reverse proxies, certificats automatisés, supervision basique. Ce que je travaille encore : observer des incidents en prod et les disséquer post-mortem, formaliser des runbooks, automatiser davantage la chaîne CI/CD pour réduire les interventions humaines.