Astuces IoT – 2

Au début des années 2000, alors que la petite société que j’avais cofondée en 1990 était encore active, nous avons décidé de répondre à un appel d’offres soumis par une société de collecte de déchets ménagers. La demande concernait un système permettant de vérifier si toutes les tournées quotidiennes de collecte avaient été réalisées. A cette époque, nous ne connaissions pas beaucoup le marché de la collecte de déchets. Mais nous nous savions suffisamment expérimentés dans les technologies que nous aurions à assembler pour répondre à l’appel d’offres : équipements et logiciel embarqués, positionnement par satellites, communications sans fil, systèmes d’information géographique, etc.

Comme ce marché était nouveau pour nous, nous avons fait ce que nous faisions habituellement dans une telle situation : nous avons essayé de réellement comprendre comment l’entreprise travaillait, à quels problèmes elle devait faire face, et pourquoi elle avait lancé l’appel d’offres. Pour cette dernière question, la réponse était claire : la société de collecte répondait à son tour à un appel d’offres de l’autorité locale. Et cet appel d’offres demandait à ce que chaque matin, la société lui fournisse des rapports listant les circuits de collecte réalisés, les circuits non réalisés (et les raisons), et les circuits réalisés alors qu’ils n’étaient pas planifiés.

Nous avons passé beaucoup de temps à parler avec le responsable de la société. Au départ, il n’était pas facile d’avoir accès à lui. Mais après quelque temps, il a compris que même si nous n’étions pas expérimentés dans son marché, nous voulions réellement résoudre ses problèmes de tous les jours de façon pérenne. Et il a accepté de répondre à plus de questions, et de nous laisser parler avec quelques encadrants et quelques conducteurs de camions. Nous avons demandé des détails à propos des différents types de véhicules utilisés, combien de temps ils passaient en collecte chaque jour, si de l’électronique était déjà installée à bord, si le conducteur était seul à bord, les raisons de non-réalisation de certains circuits de collecte planifiés, les problèmes de sécurité rencontrés, etc.

Au bout d’un moment, nous avons également compris que deux autres fournisseurs allaient répondre à l’appel d’offres. Les deux étaient expérimentés dans le domaine de la collecte de déchets, et avaient déjà fourni des systèmes à quelques grandes villes en Europe. Nous avons passé un peu de temps à réunir de l’information sur ces systèmes. Ils étaient basés sur l’architecture habituelle : équipement embarqué avec récepteur de positionnement par satellites et module GSM, application centrale (fonds de cartes numériques, rapports, etc.), et suivi de véhicules sur réseau GSM (en CSD ou SMS à l’époque). Comment pourrions-nous gagner, face à ces concurrents ?

Quelques avant de finaliser notre proposition, nous avons eu une idée. Une fois de plus, nous avons appelé le responsable de la société, car nous voulions être sûrs à propos de notre idée. Quand nous en avons parlé au responsable, il éclata de rire, et nous répondit que nous avions raison.

Quelle était notre idée ? Nous avions noté que l’appel d’offres de l’autorité locale ne contenait aucune demande pour une fonction de suivi « temps-réel ». Par conséquent, il n’y avait aucun besoin d’installer un module GSM dans chaque camion ! Nous avons donc répondu avec un système basé sur un équipement embarqué capable de stocker une journée de données. Et à la fin de la journée, les données étaient téléchargées par un câble connecté à l’équipement. Ainsi, pas de coûts récurrents (pas d’abonnement mobile) et un coût de l’équipement plus bas (pas de module GMS).

Notre client a gagné l’appel d’offres de l’autorité locale. Et par copnséquent, nous avons gagné l’appel d’offres de sa société.

La conclusion est simplement : il faut comprendre les besoins du client mieux que lui-même les comprend.

Cet exemple concerne le développement d’un système complet. Mais la façon exposée ci-dessus de considérer les besoins utilisateurs peut s’appliquer aux sous-systèmes également. Dans tous les cas, la clé est la capacité à écouter le client, à séparer la vision fonctionnelle de la vision technique, et à être expérimenté dans les domaines techniques concernés.