Comment Tohum AB a transformé ses exigences techniques, attaqué sa dette technique et fait de l'apprentissage un moteur de croissance de carrière

1. Pourquoi nous avons écrit cette histoire

Chaque start-up finit par découvrir que sa technologie n’est que la moitié du produit ; l’autre moitié est la connaissance des ingénieurs qui donnent vie à cette technologie. Chez Tohum AB — opérant depuis Göteborg, Suède et İzmir, Türkiye — nous concevons des nœuds de mesure du sol prêts pour le terrain, associant un MCU ESP32 à des capteurs NPK de précision, des batteries Li-ion, des panneaux solaires haute efficacité, une liaison SIM et des pipelines de données MQTT. Au fur et à mesure que la liste des fonctionnalités s’allongeait, nous nous sommes retrouvés à jongler avec des forks de firmware, des révisions de PCB précipitées et un backlog « choses qu’on corrigera plus tard » de plus en plus long.

Cet article est une rétrospective sur la façon dont nous avons :

1. Défini nos exigences techniques de manière à équilibrer la précision agronomique, les besoins d’ultra-basse consommation et les contraintes de fabrication.

2. Audité et quantifié notre dette technique, des pilotes BLE buggués aux schémas d’arbres d’alimentation dupliqués.

3. Construit un plan d’apprentissage basé sur une matrice de compétences qui transforme les lacunes en opportunités de croissance plutôt qu’en sources de stress.

4. Intégré le développement de carrière dans notre rythme d’ingénierie quotidien afin que l’avenir de chaque employé soit pris aussi au sérieux que l’avenir de chaque produit.

Nous espérons que ce playbook sera utile, que vous soyez en train d’architecturer votre premier nœud capteur ou de faire évoluer une flotte de dizaines de milliers d’appareils.

2. Cadrer la mission — d’« un gadget sympa » à des résultats mesurables

Notre vision fondatrice était simple : donner aux agriculteurs une vision abordable et riche en télémétrie de la santé des sols afin qu’ils puissent optimiser les engrais et l’irrigation avec une précision scientifique. Transformer cette vision en backlog d’ingénierie nécessitait un langage compris de tous les stakeholders — marketing, agronomes de terrain, ingénieurs firmware et concepteurs matériel.

Nous avons donc rédigé chaque exigence de premier niveau comme un résultat visible par l’utilisateur suivi de métriques d’ingénierie :

• « Un technicien de terrain peut installer une sonde et voir les données dans le tableau de bord en 5 min. »

  • Provisionnement Wi-Fi 2,4 GHz ou BLE Soft-AP ; fallback vers un APN préchargé pour la cellulaire.

  • Les valeurs initiales de pH, CE et température du sol doivent apparaître dans Grafana dans les 300 s.

• « Les nœuds doivent fonctionner sans surveillance pendant un hiver nordique complet sans remplacement de batterie. »

  • Consommation moyenne ≤ 80 µA sur 24 h ; quiescent en deep-sleep ≤ 5 µA.

  • Un panneau de 6 W + une batterie 18650 de 3 500 mAh doivent respecter le budget énergétique à 55° N avec 2 h d’insolation.

• « Les trous de données causés par la perte de couverture doivent être comblés automatiquement. »

  • Buffer circulaire LittleFS de 4 MiB ; carte SD en option.

  • Renvoi MQTT QoS 1 avec backoff exponentiel lors de la reconnexion.

Avec des résultats clairs, les compromis sont devenus explicites : un buffer local plus grand augmente le coût BOM ; un échantillonnage plus fréquent améliore la résolution agronomique mais draine la batterie. Parce que chaque exigence pouvait être tracée vers des chiffres concrets, nous avons évité le piège des fonctionnalités « sympas à avoir » qui s’infiltrent dans les cartes de révision A.

3. Décomposition de la pile technologique

Ensuite, nous avons décomposé la solution en six domaines d’intérêt, chacun porté par un « tech steward » qui possédait les exigences, les registres de risques et les epics Jira :

Une « Architecture Canvas » d’une seule page visualisait les dépendances : la carte capteur de sol alimente les données I²C vers le MCU ; le sous-système d’alimentation rapporte le SoC via un compteur de coulombs ; le modem partage le bus UART avec le débogage RS-485 ; le moteur de règles cloud diffuse les données vers InfluxDB pour Grafana.

Ce canvas est devenu la table des matières de tous les documents de conception ultérieurs, empêchant la pensée en silos et garantissant que chaque ingénieur savait qui contacter quand une spécification changeait.

4. Quantifier la dette technique — transformer les anecdotes en chiffres

Comme beaucoup de start-ups, nous avions accumulé des raccourcis du type « on corrigera ça après le demo day » :

• Firmware

  • APN codés en dur dans trois arbres source différents.

  • Routines ADC copiées-collées avec des constantes de mise à l’échelle magiques.

• Matériel

  • Trois changements de valeur de résistance corrigés par des fils volants dans le lot pilote.

  • Aucune convention de nommage cohérente pour les points de test.

• Processus

  • Scripts Bash ponctuels pour flasher 50 unités sur la ligne de production.

  • Connaissance tribale sur quel commit du SDK fonctionnait avec quelle révision de carte.

Nous avons adopté un audit en trois étapes similaire à la métaphore de la dette technique de Ward Cunningham :

1. Inventaire — un « safari de la dette » réunissant toute l’équipe a produit 126 éléments dans une page Confluence.

2. Gravité & taux d’intérêt — chaque élément était noté de 1 à 5 pour l’impact et de 1 à 5 pour le coût de correction ultérieure.

3. Estimation du principal — heures nécessaires si corrigé immédiatement.

Le résultat ressemblait à :

Les éléments les mieux notés ont été promus aux backlogs de sprint. Les plus faibles sont restés dans la « banquise » mais avec des dates d’expiration explicites. Ce regard quantitatif a dépersonnalisé les discussions : ce sont les chiffres qui décidaient de la priorité, pas la voix la plus forte.

5. Cartographier les compétences sur le produit — la matrice en T

Parallèlement à l’audit de la dette, nous avons réalisé qu’une partie de la « dette » était en réalité un déficit de compétences. Nous avons emprunté le cadre à cinq niveaux vu précédemment (Débutant absolu → Expert) et listé 25 compétences (C/C++, ESP-IDF, FreeRTOS, Git, PlatformIO, Linux CLI, Unity Test, CI/CD, Jira/Confluence, Électronique, Conception PCB, Budget énergétique, Gestion de batterie, Comms cellulaires, Protocoles IoT, TLS, Calibration de capteurs, Journalisation de données, OTA, Théorie du contrôle, Python/Bash, Tableaux de bord cloud, Conformité réglementaire, Outils de documentation).

Chaque ingénieur s’est auto-évalué et un tech lead a modéré pour calibrer. Les résultats ont formé une heat map :

Name   C/C++ ESP-IDF LTE  PCB  MQTT Cloud ...
Ali      4      3      2    5    4     2
Elif     2      2      4    3    3     5
Mert     5      4      1    2    3     2

Nous appelons cela la matrice en T — chacun est profond dans un pic, large dans les bases. Cela a immédiatement mis en évidence les risques : si Ali (niveau LTE 2) partait en vacances, les problèmes cellulaires pourraient bloquer un sprint. Cela a aussi éclairé les parcours de croissance : Elif pouvait encadrer le cloud tout en apprenant l’ESP-IDF de Mert.

6. Construire le plan d’apprentissage — des lacunes aux objectifs

Un plan d’apprentissage n’est crédible que s’il relie aux besoins du produit et à la motivation individuelle. Nous avons pris trois mesures concrètes :

1. Gammes de compétences alignées sur les jalons de la roadmap
   T3 : secure boot et chiffrement flash → tout le monde au niveau 3 en mbedTLS.
   T4 : déploiement delta-OTA → deux développeurs firmware au niveau 4 en journalisation de données et conception de partitions.

2. Pratique intégrée
   – Sessions de pair-programming deux fois par semaine en faisant tourner mentor/mentoré.
   – « Friday Spike » : bac à sable de 4 h pour bidouiller sur tout ce qui touche au thème de la semaine — maquettes de filtre de Kalman, diagrammes de carte PlantUML, etc.

3. Métriques de progression visibles
   – Présentations éclair mensuelles « montrez ce que vous avez appris ».
   – Tableau Jira Goals avec des epics personnelles comme « Elif monte l’ESP-IDF à 3 : exemple OTA livré. »

Nous avons alloué 10 % de la vélocité de sprint explicitement aux tâches d’apprentissage. La finance a d’abord questionné le coût en capacité, mais les chiffres de rétention se sont améliorés : le turnover volontaire est tombé à 0 % sur 18 mois.

7. La boucle de développement de carrière — l’ingénierie d’abord, pas les RH

Les cycles d’évaluation traditionnels semblaient inadéquats. Nous les avons remplacés par un Career Kanban léger :

Les ingénieurs déplacent les cartes à leur propre rythme ; les leads interviennent uniquement pour débloquer ou célébrer. Cette fluidité reflète le fonctionnement des pull requests — l’apprentissage n’est qu’une autre branche.

8. Résultats sur le terrain — moins d’arrêts, des agriculteurs plus satisfaits

Douze mois après le lancement du cadre :

• Le backlog de bugs a fondu de 48 %.

• La cadence de release firmware est passée de trimestrielle à mensuelle.

• L’autonomie de la batterie a dépassé l’objectif hivernal initial de 18 %.

• Les tickets de support pour les déconnexions cellulaires ont chuté de 60 %.

Plus révélateur encore, le délai entre la spécification et le premier prototype validé est passé de huit semaines à 4,5. Les ingénieurs ont attribué cela au cross-training : le concepteur PCB qui a atteint le niveau 3 en Python a écrit un script de calibration qui a fait gagner une semaine de travail de banc d’essai.

9. Prendre soin de l’avenir — pourquoi l’apprentissage fait partie de notre charte ESG

Nous positionnons l’apprentissage continu non seulement comme un avantage RH, mais comme un impératif environnemental et social :

• Environnemental — Un firmware mieux conçu signifie moins de visites sur le terrain et une empreinte CO₂ plus faible.

• Social — Des employés plus qualifiés deviennent des ambassadeurs tech locaux, stimulant l’innovation régionale.

• Gouvernance — Des matrices de compétences documentées et des promotions transparentes réduisent les biais et renforcent la conformité.

Chaque trimestre, nous publions un « Learning Impact Report » interne montrant les corrélations entre les heures de formation et les OKR clés (densité de bugs, efficacité énergétique). Le conseil l’examine aux côtés des chiffres de revenus — la preuve que les métriques humaines méritent un temps de parole égal en salle de réunion.

10. Leçons apprises et conseils pour les autres équipes

1. Rédigez d’abord les exigences axées sur les résultats ; les choix technologiques suivent naturellement.

2. Quantifiez la dette technique pour que les arguments deviennent des maths, pas de l’émotion.

3. Les matrices de compétences visuelles révèlent les goulots d’étranglement de talents plus vite que les organigrammes.

4. Allouez du temps concentré (nous avons choisi 10 %) pour rendre l’apprentissage crédible.

5. Liez l’apprentissage au code réel — une PR fusionnée enseigne plus que n’importe quel MOOC.

6. Célébrez les petites victoires ; les présentations éclair l’emportent sur les diaporamas pour partager le savoir tacite.

7. Connectez publiquement l’apprentissage aux KPI produit pour obtenir le soutien exécutif.

11. Quelle suite pour Tohum AB

Notre roadmap 2026 inclut la double connectivité NB-IoT + LoRa, des prédictions nutritives pilotées par l’IA et un boîtier v6 robuste ciblant les opérations agricoles de lavage à haute pression IP69K. Chaque frontière engendre de nouvelles colonnes dans la matrice de compétences — ML ultra-basse consommation, plongées approfondies dans la couche MAC LoRaWAN, laboratoires d’infiltration haute pression. Le cadre perdure : nous répétons le cycle exigences-dette-apprentissage à chaque bond en avant.

12. Un dernier mot sur les personnes

Les puces de silicium vieillissent ; les panneaux solaires se dégradent ; même le sol le plus riche finit par avoir besoin d’être reconstitué. Le seul actif dont la valeur se capitalise indéfiniment est le potentiel humain. En concevant notre processus d’apprentissage avec la même rigueur que nous appliquons aux schémas et au code, nous avons découvert une boucle vertueuse : de meilleurs produits financent plus d’apprentissage, qui génèrent de meilleures carrières, qui à leur tour produisent de meilleurs produits.

Si vous ne retenez qu’une chose de notre histoire, que ce soit celle-ci : investissez dans vos ingénieurs comme vous investissez dans votre chimie de batterie. Les deux stockent de l’énergie, mais un seul peut inventer l’avenir.