Faire ou acheter : pourquoi développer une application de gestion des prestataires en interne coûte plus cher qu'on ne le croit

La conversation commence toujours de la même façon. L'équipe de transformation numérique d'un OEM observe comment ses prestataires de services sur pales collectent les données terrain et se dit : « Nous pourrions développer quelque chose de mieux en interne. Nous connaissons nos processus. Nous avons des développeurs. Quelle difficulté y a-t-il ? »

C'est un réflexe compréhensible. L'OEM voit des données fragmentées arriver de ses prestataires sous des formats disparates, sait exactement à quoi il souhaite que le résultat ressemble, et conclut que développer un outil sur mesure est la voie la plus directe pour résoudre le problème. Dans certains cas, il a raison. Mais dans la plupart des cas, le coût réel de développer, déployer et maintenir une application terrain destinée aux prestataires est trois à cinq fois supérieur à l'estimation initiale.

Cet article décrit les origines de ces coûts cachés et propose un cadre de décision pour déterminer quand développer est judicieux et quand cela ne l'est pas.

L'attrait du développement interne

Avant d'explorer les coûts, il convient de reconnaître pourquoi le développement interne est séduisant. Les arguments sont réels :

• Contrôle total sur les fonctionnalités — l'outil fait exactement ce que vous souhaitez, ni plus ni moins
• Aucune dépendance vis-à-vis d'un fournisseur — vous possédez le code, la feuille de route et les données
• Intégrations personnalisées — l'application se connecte directement à vos systèmes internes sans middleware
• Propriété intellectuelle — le logiciel devient un actif propriétaire

Ce sont des avantages légitimes. La question n'est pas de savoir s'ils sont réels, mais s'ils valent le coût total de leur réalisation. D'après notre expérience auprès des prestataires de services sur pales depuis plus d'une décennie, la réponse est généralement non, et voici pourquoi.

Les catégories de coûts cachés

1. L'expérience utilisateur terrain est une discipline à part entière

Développer une application pour des utilisateurs en bureau est un problème bien maîtrisé. La développer pour des techniciens travaillant à 80 mètres de hauteur en rappel, gantés, sous la pluie, avec une tablette dont le protège-écran est fissuré, c'est une toute autre affaire.

Chaque interaction doit fonctionner d'une seule main. Les boutons doivent être suffisamment grands pour être actionnés avec des gants. Les formulaires doivent sauvegarder leur état en permanence, car un technicien peut être appelé à s'interrompre en pleine saisie. La prise de photo doit gérer automatiquement le balisage des métadonnées, car personne ne saisit des descriptions en étant suspendu à une pale. Et tout cela doit fonctionner sur une gamme d'appareils, du dernier iPad Pro à une tablette Samsung vieille de cinq ans achetée en gros par un prestataire.

Le développement d'applications d'entreprise coûte généralement entre 150 000 et 500 000 dollars pour la construction initiale². Une application terrain répondant aux exigences ci-dessus se situe fermement en haut de cette fourchette, et c'est avant de tenir compte de la recherche utilisateur, des tests sur le terrain et de la reconception itérative qu'un produit utilisable nécessite.

2. Le mode hors ligne est un défi d'ingénierie qui se compte en mois

De nombreux sites de parcs éoliens disposent d'une connectivité cellulaire limitée ou inexistante. Une application nécessitant une connexion internet permanente est inutilisable sur le terrain. Cette exigence semble simple : « il suffit de mettre les données en cache localement et de les synchroniser dès que la connectivité revient ». En pratique, c'est l'un des problèmes les plus complexes de l'ingénierie mobile.

Le mode hors ligne implique de résoudre les questions suivantes :

• Résolution de conflits — que se passe-t-il lorsque deux techniciens modifient le même enregistrement hors ligne et synchronisent tous les deux ultérieurement ?
• Intégrité des données — comment garantir qu'aucun enregistrement n'est perdu lors de la synchronisation, même si l'application plante en cours de téléversement ?
• Gestion du stockage — les photos d'inspection sont volumineuses. Une seule campagne sur une éolienne peut générer des gigaoctets d'images. L'application doit gérer intelligemment le stockage local sans saturer l'appareil.
• Gestion de la file d'attente — la synchronisation doit traiter gracieusement des milliers d'enregistrements en attente, avec une logique de réessai, un retour sur l'avancement et la capacité de reprendre les téléversements interrompus.

Nous avons vu des applications commandées par des OEM qui semblaient soignées en salle de démonstration et qui ont subi des défaillances catastrophiques lors de la première campagne offshore, parce que l'architecture hors ligne n'avait pas été éprouvée sur le terrain. Parvenir à un résultat fiable ajoute généralement trois à six mois de développement et une complexité de maintenance permanente.

3. La prise en charge multilingue ne se résume pas à la traduction

Les services sur pales sont un secteur mondial. Les prestataires et leurs techniciens interviennent en Europe, en Amérique, en Asie-Pacifique et au-delà. Une application qui ne fonctionne qu'en anglais ne sera pas adoptée au Danemark, en Allemagne, en Espagne ou en Pologne. Et la prise en charge multilingue est bien plus complexe que la simple traduction des chaînes de caractères.

Il faut gérer :

• Le basculement dynamique entre les langues (les techniciens travaillent souvent dans des équipes multilingues)
• Les formats de date, d'heure et de nombre propres à chaque locale
• Les ajustements de mise en page pour les langues avec des mots plus longs (les noms composés allemands feront exploser toute mise en page conçue pour l'anglais)
• La maintenance continue des traductions à mesure que les fonctionnalités évoluent

Chaque nouvelle langue accroît la charge de test. Chaque modification d'interface doit être validée dans chaque locale prise en charge. Ce n'est pas un coût ponctuel ; c'est un multiplicateur permanent sur chaque cycle de développement futur.

4. La maintenance continue est là où réside le véritable enjeu financier

La construction initiale est la partie la moins coûteuse. Les références sectorielles montrent régulièrement que les coûts de maintenance annuels représentent 15 à 20 % du budget de développement initial¹. Pour une construction à 400 000 dollars, cela représente 60 000 à 80 000 dollars par an, chaque année, indéfiniment.

Cela couvre :

• Les mises à jour des systèmes d'exploitation mobiles — Apple et Google publient des versions majeures annuellement. Chacune peut casser des fonctionnalités existantes, nécessitant des tests de régression et des correctifs sur l'ensemble de votre parc d'appareils.
• Les correctifs de sécurité — une application destinée aux prestataires qui gère des données personnelles, des localisations GPS et des informations de sites clients exige une maintenance de sécurité continue. Une vulnérabilité non corrigée et vous avez un incident de protection des données.
• La fragmentation des appareils — les prestataires utilisent un mélange d'appareils iOS et Android, sur plusieurs générations. Tester et prendre en charge cette matrice représente une charge permanente.
• Les corrections de bogues et les demandes des utilisateurs — une fois l'application en production, les demandes de fonctionnalités et les rapports de bogues ne s'arrêtent jamais. Quelqu'un doit trier, prioriser, corriger, tester et publier. Cela représente au moins un développeur à temps plein, souvent davantage.
• Les tests — chaque modification, aussi mineure soit-elle, nécessite des tests de régression sur les appareils, les systèmes d'exploitation et les conditions réseau (en ligne, hors ligne, intermittent). Les suites de tests automatisés doivent être construites et maintenues. Des tests manuels QA sont nécessaires pour les scénarios spécifiques au terrain qui ne peuvent pas être simulés en laboratoire. Il s'agit d'un coût permanent qui s'accroît avec chaque fonctionnalité ajoutée.

Sur cinq ans, le coût total de maintenance d'une application sur mesure peut facilement dépasser le coût de construction initial, avant d'ajouter la moindre nouvelle fonctionnalité.

5. La complexité des intégrations s'accumule dans le temps

L'application doit échanger des données avec plusieurs systèmes tiers : bases de données de registres de formation, plateformes d'ordres de travail des OEM, outils CRM, systèmes ERP et tout ce que l'entreprise utilise par ailleurs. Chaque intégration est un mini-projet : mapping d'API, authentification, gestion des erreurs, logique de réessai, transformation des données.

L'intégration initiale est gérable. Le coût continu ne l'est pas. Les API tierces évoluent. Les plateformes ERP publient de nouvelles versions. Les points d'accès sont dépréciés. Chaque modification oblige votre équipe à enquêter, mettre à jour, tester et déployer. Si vous avez cinq intégrations, vous maintenez cinq cibles mouvantes en parallèle de votre propre base de code.

6. L'adoption par les prestataires est le coût le plus difficile à quantifier

C'est le risque qui détermine le succès ou l'échec de l'investissement. Si les prestataires n'utilisent pas l'application, rien d'autre n'a d'importance. Vous avez dépensé des centaines de milliers d'euros pour un outil qui reste inutilisé sur des tablettes dans des tableaux de bord de camionnette.

L'adoption par les prestataires échoue lorsque :

• L'application est trop complexe (conçue par des développeurs qui n'ont jamais travaillé en hauteur)
• L'application est trop lente (les techniciens n'attendront pas des écrans de chargement entre les éoliennes)
• L'application ne fonctionne pas hors ligne (voir ci-dessus)
• L'application ajoute des étapes sans bénéfice visible pour le technicien (perçue comme une surveillance plutôt qu'un soutien)
• La formation est trop longue (les prestataires se succèdent lors des campagnes et ne peuvent pas se permettre des jours d'intégration)

Les outils développés spécifiquement pour ce secteur résolvent le problème d'adoption parce que c'est leur seule raison d'être. Un fournisseur dont l'ensemble de l'activité dépend de l'adoption par les travailleurs terrain investira davantage dans la recherche sur l'utilisabilité, les tests terrain et la conception itérative qu'une équipe informatique interne ne peut jamais justifier pour un seul projet.

Ce que « acheter » signifie réellement dans ce secteur

Lorsque les OEM évaluent l'option « acheter », ils comparent parfois avec des plateformes génériques de gestion de services terrain comme ServiceMax, IFS ou les modules de services terrain de leur ERP existant. Ces comparaisons sont compréhensibles, mais trompeuses. Les logiciels d'entreprise de gestion de services terrain sont conçus pour la gestion des installations, les services publics et les télécommunications. Ils n'ont pas été construits pour les flux de travail d'inspection des pales, la classification des dommages, les contrôles de sécurité pour l'accès par cordes ou les séquences de tâches spécifiques aux OEM.

L'option « acheter » dans les services sur pales d'éoliennes désigne une plateforme construite spécifiquement pour ce secteur. Une plateforme qui gère déjà le mode hors ligne, la prise en charge multilingue, les intégrations OEM et les structures de données spécifiques aux inspections et réparations de pales. Une plateforme dont la feuille de route est pilotée par le même secteur dans lequel vous opérez, et non par les besoins de la gestion des installations ou des services terrain en télécommunications.

L'économie est claire. Une plateforme spécialisée répartit son coût de développement sur l'ensemble de ses clients. Chaque client bénéficie de fonctionnalités issues de la totalité de la base utilisateurs. Le coût par utilisateur est une fraction de ce qu'un développement sur mesure exigerait, et l'OEM obtient un produit déjà éprouvé lors de campagnes réelles, et non un prototype qui reste à valider.

Un cadre de décision

Développer en interne est judicieux lorsque :

• Votre processus est genuinement unique et aucun fournisseur ne le couvre (c'est plus rare que la plupart des organisations ne le croient)
• Vous disposez d'une équipe logicielle dédiée ayant une expérience des applications terrain (pas seulement des développeurs web)
• Vous êtes prêt à financer la maintenance continue pendant au moins cinq ans
• Vous avez une stratégie d'adoption par les prestataires, et pas seulement de déploiement

Acheter est plus judicieux lorsque :

• Votre processus de base est standard (inspections, réparations, feuilles de temps, contrôles de sécurité) mais vos exigences en matière de données sont spécifiques
• Vous devez être opérationnel en quelques mois, pas en quelques années
• Vos prestataires utilisent déjà la plateforme (adoption immédiate, aucun écart de formation)
• Vous souhaitez posséder les données sans posséder le logiciel
• Le temps de votre équipe d'ingénieurs est mieux investi dans la technologie des turbines que dans les logiciels de flux de travail des prestataires

La vraie question

La décision de faire ou d'acheter n'est pas vraiment une question de technologie. C'est une question de ce qui est au cœur de votre activité et de ce qui ne l'est pas. Les grands OEM avec une empreinte mondiale ont absolument besoin de capacités de développement logiciel internes. Les systèmes ERP, les plateformes de chaîne d'approvisionnement et l'infrastructure de surveillance des turbines sont essentiels à la mission et justifient des équipes dédiées. Mais une application de services terrain pour prestataires est une tout autre proposition. C'est un outil spécialisé et sectoriel qui doit évoluer rapidement, fonctionner dans des conditions d'utilisation difficiles et obtenir l'adhésion d'une base de prestataires fragmentée que votre organisation ne contrôle pas directement. Ce n'est pas un défi de compétence fondamentale. C'est un défi d'expertise sectorielle, et cette expertise prend des années de déploiement terrain à développer.

Vos équipes internes devraient construire ce qui différencie vos turbines sur le marché, pas ce qui gère les prestataires qui les entretiennent. La bonne nouvelle est que le problème consistant à extraire des données structurées et fiables des équipes terrain des prestataires a déjà été résolu par des acteurs dont l'ensemble de l'activité dépend de l'exactitude de ce résultat. Si vous évaluez cette décision, nous serions heureux de vous faire part de ce qu'une décennie de développement de logiciels terrain nous a appris.

Références

1. Plusieurs sources sectorielles, dont Noloco, CloseLoop et Cubix, indiquent que les coûts annuels de maintenance des applications représentent 15 à 20 % du budget de développement initial. Voir : Custom App Development Cost in 2025 (noloco.io), Mobile App Development Cost Breakdown (cubix.co), Mobile App Development Cost in 2025 (closeloop.com).
2. Le coût de développement des applications mobiles d'entreprise est généralement estimé à 150 000 à 500 000 dollars et plus pour des constructions complexes et riches en fonctionnalités. Sources : App Development Costs 2026: Pricing Guide (topflightapps.com), Cost to Develop an Enterprise App in 2025 (syncrasytech.com), Mobile App Development Cost Breakdown (chopdawg.com).

← Retour à Field Notes