Si vous cherchez à faire financer un projet IoT dans votre entreprise, vous maîtrisez probablement la technologie. Vous avez choisi les capteurs, testé la couverture LoRaWAN, peut-être monté un dashboard sur un compte gratuit un week-end. Votre présentation reflète ce travail : slide d’architecture, liste des appareils, options de connectivité, une capture d’écran des données en direct. Tout le monde hoche la tête.
Puis rien ne se passe. Le retour est une variante de “intéressant, revenez le trimestre prochain”, et au trimestre suivant les mêmes slides récoltent les mêmes hochements de tête. Le projet n’est jamais refusé et jamais validé, ce qui est pire : un refus, au moins, vous dit quoi corriger.
Le problème vient rarement du dirigeant. Un dirigeant débloque un budget face à un problème métier qu’il reconnaît déjà, à un chiffre qu’il peut inscrire dans un plan et à un risque qu’il peut borner. Une présentation technique ne lui donne rien de tout cela. Elle lui demande de traduire lui-même des capteurs en économies, en réunion, sous le regard des autres. La plupart ne le feront pas : ils reportent.
La solution : construire l’argumentaire à l’envers, en partant de ce dont ils ont besoin pour pouvoir dire oui.
Partez d’un seul indicateur que la direction suit déjà
Chaque dirigeant a une courte liste de chiffres qu’il regarde chaque semaine : heures d’arrêt non planifié, coût énergétique par site, taux de pertes, nombre d’interventions sur site par mois, heures supplémentaires. Votre argumentaire doit s’accrocher à un seul d’entre eux.
La tentation est de lister tous les gains que les capteurs pourraient apporter, parce que le dossier paraît plus solide. Il est plus faible : six gains, ce sont six chiffres que le dirigeant doit croire, et le plus fragile entraîne les autres vers le bas. Un seul indicateur, avec une valeur actuelle sur laquelle tout le monde s’accorde déjà et une cible que vous pouvez défendre, c’est quelque chose qu’il peut répéter en une phrase à son propre patron.
Choisissez cet indicateur en posant la question, pas en devinant. Vingt minutes avec le responsable des opérations, sur ce qui lui vaut des appels en pleine nuit, suffisent en général à le faire ressortir. Si les capteurs ne déplacent aucun chiffre suivi par la direction, mieux vaut le découvrir avant de dépenser votre capital politique.
Montrez trois ans de coûts, pas la première facture
La deuxième chose dont un dirigeant a besoin, c’est un chiffre qui ne le mettra pas en difficulté plus tard. Les projets IoT sont connus pour leur petit budget de première année suivi de surprises : frais de connectivité par appareil, matériel de remplacement, le temps d’ingénierie que personne n’a chiffré, les travaux d’intégration dès que l’équipe ERP entre en jeu. Le vrai coût d’un déploiement IoT pour le marché intermédiaire est bien documenté, et la plupart des dirigeants se sont déjà fait piéger par le même schéma sur un autre projet.
Posez le total à trois ans sur une seule slide : matériel et installation, connectivité, plateforme et temps interne d’exploitation. Dites quelles lignes sont des estimations et quelle est l’amplitude de la fourchette. “Environ 140 000 $ sur trois ans, la ligne plateforme variant selon le nombre d’appareils” vaut mieux qu’un chiffre précis de 38 000 $ en première année dont toute la salle soupçonne qu’il est incomplet. Le comparatif du prix des plateformes IoT sur trois ans montre comment les coûts de plateforme évoluent quand le nombre d’appareils augmente.
Placez ensuite l’indicateur à côté de ce chiffre. Si une heure d’arrêt coûte 9 000 $ et que la cible est de huit heures en moins par an, le dirigeant fait le calcul sans votre aide. C’est en général au moment où il le fait lui-même que le ton de la réunion change.
Proposez un pilote avec un critère d’arrêt et une date
Les dirigeants craignent moins de dépenser de l’argent que de le mettre dans quelque chose qu’on ne peut plus arrêter. Une “phase un” sans horizon se lit comme un engagement permanent, et les engagements permanents sont reportés.
Un pilote avec un critère d’arrêt se lit autrement : un nombre fixe d’appareils sur un seul site, une durée fixe (souvent quatre-vingt-dix jours), une mesure liée à l’indicateur et une phrase écrite qui dit quel résultat met fin au projet. “Si nous ne détectons pas au moins 80 % des pannes de compresseur consignées dans le journal de maintenance pendant le pilote, nous arrêtons et nous passons le coût du pilote en perte” donne une sortie au dirigeant. Une sortie claire le rend beaucoup plus disposé à entrer.
Fixez une date de décision. Pas “nous examinerons les résultats” mais “le 12 décembre, nous nous réunissons et décidons d’étendre, d’ajuster ou d’arrêter”. Le guide de planification pour chefs de projet non techniciens explique comment cadrer le pilote pour que la mesure reste propre.
Dimensionnez le pilote pour que son coût reste dans le pouvoir de signature du dirigeant qui valide. Un pilote de 15 000 $ qu’un directeur signe seul avance en une semaine. Un pilote de 60 000 $ qui exige un comité attend le comité.
Faites la démo sur leur téléphone, pas sur vos slides
Une capture d’écran de dashboard prouve que vous savez faire un dashboard. Une vue en direct sur le téléphone du dirigeant prouve que le système existe et qu’il pourrait s’en servir sans vous.
Avec quelques appareils réels qui envoient déjà des données, montez un petit portail TagoRUN, créez un utilisateur pour le dirigeant et demandez-lui d’installer l’application mobile TagoRUN et de s’y connecter avant la réunion. Quand vous dites “la chambre froide côté est affiche 3,8 degrés en ce moment”, il peut vérifier. Configurez une Action pour qu’une alerte arrive sur son téléphone pendant la réunion, et la discussion ne porte plus sur la question de savoir si le système fonctionne.
Limitez la démo à l’indicateur : un dashboard, deux ou trois widgets, une alerte. Quinze graphiques provoquent quinze questions sur les graphiques et aucune sur le budget.
Répondez honnêtement à la question “pourquoi ne pas le construire nous-mêmes sur AWS”
Quelqu’un dans la salle posera la question, souvent le CTO. Ne l’esquivez pas, et ne prétendez pas que l’alternative est inviable. Des entreprises construisent en permanence sur AWS IoT Core, sur ThingsBoard et sur des stacks maison, et certaines ont raison de le faire.
La réponse honnête porte sur le temps et les effectifs, pas sur la faisabilité. Construire vous-même l’ingestion, le stockage, la gestion des utilisateurs, les dashboards, les alertes et l’accès mobile place une équipe d’ingénierie entre le pilote et la date de décision. L’article AWS IoT Core face à une plateforme IoT managée détaille dans quels cas chaque voie se justifie. Pour l’argumentaire, ce qui compte, c’est que le calendrier du pilote que vous venez de proposer suppose de configurer, pas de construire. Si la direction préfère construire, le calendrier et le coût sur trois ans changent tous les deux, et vous devez dire de combien.
Les dirigeants respectent cette réponse parce qu’elle ne sonne pas comme un discours de fournisseur. On y entend plutôt quelqu’un qui réfléchit à l’endroit où les ingénieurs de l’entreprise devraient passer leur temps.
Ce qu’il faut laisser de côté
L’essentiel de ce qui donne à une présentation technique son air de sérieux est aussi ce qui la bloque. Laissez de côté :
- Le schéma d’architecture. Gardez-le en annexe pour celui qui le demandera.
- Le choix des protocoles. LoRaWAN ou cellulaire, c’est une décision que vous avez déjà prise, pas un arbitrage à leur soumettre.
- Les cas d’usage futurs. L’extension se discute à la date de décision, une fois que le pilote a un résultat.
- Les statistiques sectorielles sur l’adoption de l’IoT. Elles signalent que vous n’avez pas trouvé de chiffre dans votre propre entreprise.
- La liste des fonctionnalités de la plateforme. Le dirigeant valide un pilote face à un indicateur, il ne choisit pas un logiciel.
L’argumentaire qui passe tient sur une page. Les porteurs de projet qui obtiennent un financement IoT sont rarement ceux qui ont le meilleur dossier technique. Ils ont fait le travail de traduction à la place du dirigeant, si bien que la seule chose qui restait à faire en réunion était de dire oui.
