La bonne solution PdM : développer ou acheter ?

Vous avez décidé que la maintenance prédictive mérite l'investissement. La question suivante : la développer vous-même ou acquérir une plateforme ?

Les deux approches fonctionnent. Le bon choix dépend de votre équipe, de vos délais et de ce que vous cherchez à optimiser.

La voie du développement interne

Ce qu'elle exige : Une équipe d'ingénierie des données (2-3 ingénieurs) plus un ingénieur ML, 6 à 12 mois pour le MVP, et une maintenance continue.

Où le développement interne gagne

Contrôle total sur les modèles. Vous entraînez sur vos équipements exacts et vos modes de défaillance.
Flexibilité d'intégration. SCADA propriétaire de 2008 ? Vous construisez les connecteurs exacts dont vous avez besoin.
Pas de tarification par actif. À très grande échelle (plus de 10 000 actifs), le coût marginal se réduit à l'infrastructure.

Où le développement interne pose problème

Délai avant la valeur. Les équipements tombent en panne pendant que vous construisez le pipeline.
Le problème des 80 %. L'ingénierie des données consomme 80 % de l'effort. Vous ne construisez pas un modèle — vous construisez une plateforme de données distribuée en temps réel.
Maintenance continue. Les modèles dérivent. Kafka a besoin de mises à jour. C'est un effectif permanent.
Démarrage à froid pour le ML. Sans bases préentraînées, vos modèles partent de zéro.

La voie de l'achat

Ce qu'elle exige : Évaluation des fournisseurs (2-4 semaines), déploiement pilote (1-2 semaines), mise en production (2-4 semaines).

Où l'achat gagne

Délai immédiat avant la valeur. Les modèles préentraînés détectent les anomalies dès le premier jour.
Maturité opérationnelle. Le fournisseur a déjà résolu la collecte en bordure, l'ingénierie des caractéristiques, le service des modèles et la déduplication des alertes.
Apprentissage transversal entre secteurs. Les modèles entraînés sur plusieurs clients transfèrent des connaissances.
Coût prévisible. La tarification par actif signifie que vous connaissez le coût avant de commencer.

Où l'achat pose problème

Dépendance au fournisseur. Vos prédictions dépendent d'un tiers.
Moins de personnalisation. Vous souhaiterez peut-être une architecture de modèle spécifique que la plateforme ne prend pas en charge.
Les données quittent votre réseau. (Bien que les architectures edge-hybrides règlent ce problème.)

Coût total de possession sur 3 ans

L'argument « développer est moins cher à grande échelle » est courant, mais rarement étayé par des chiffres réels. Voici une comparaison illustrative du TCO sur trois points d'échelle — l'objectif est de montrer la structure des coûts, et non les euros exacts (consultez les tarifs actuels pour les tarifs SaaS réels) :

| Composante de coût | Développer (100 actifs) | Acheter (100 actifs) | Développer (500 actifs) | Acheter (500 actifs) | Développer (2 000 actifs) | Acheter (2 000 actifs) | |---|---|---|---|---|---|---| | Année 1 : Développement | 350 000 € | 0 € | 350 000 € | 0 € | 450 000 € | 0 € | | Année 1 : Infrastructure | 40 000 € | Incluse | 80 000 € | Incluse | 180 000 € | Incluse | | Année 1 : Licence/SaaS | 0 € | 60 000 € | 0 € | 180 000 € | 0 € | 480 000 € | | Année 2 : Maintenance/Dev | 180 000 € | 0 € | 220 000 € | 0 € | 280 000 € | 0 € | | Année 2 : Infrastructure | 40 000 € | Incluse | 80 000 € | Incluse | 180 000 € | Incluse | | Année 2 : Licence/SaaS | 0 € | 60 000 € | 0 € | 180 000 € | 0 € | 480 000 € | | Année 3 : Maintenance/Dev | 180 000 € | 0 € | 220 000 € | 0 € | 280 000 € | 0 € | | Année 3 : Infrastructure | 40 000 € | Incluse | 80 000 € | Incluse | 180 000 € | Incluse | | Année 3 : Licence/SaaS | 0 € | 60 000 € | 0 € | 180 000 € | 0 € | 480 000 € | | Total 3 ans | 830 000 € | 180 000 € | 1 030 000 € | 540 000 € | 1 550 000 € | 1 440 000 € |

Hypothèses clés : Les coûts de développement interne incluent 2 ETP ingénieurs données (90 000 €/an chacun) + 1 ETP ingénieur ML (100 000 €/an) pour le développement, réduit à 1,5 ETP pour la maintenance continue. L'achat est modélisé à un tarif SaaS représentatif par actif qui diminue avec le volume — consultez les tarifs actuels pour le tarif à votre échelle. L'infrastructure comprend le calcul cloud, le stockage, Kafka et les bases de données. Ces chiffres sont illustratifs de la structure des coûts, et ne constituent pas un devis.

La conclusion structurelle s'applique quelle que soit la tarification exacte : Développer implique un coût fixe élevé en amont (développement + une équipe ML/données permanente), tandis qu'Acheter est un abonnement prévisible sans risque de construction. Le point de croisement — où développer revient moins cher par an — se situe généralement sur de grandes flottes (~1 500-2 000+ actifs), et seulement si vous disposez déjà de l'équipe. En dessous, Acheter est généralement moins cher en coût total ; à toute échelle, il gagne en délai avant la valeur (semaines contre mois). Vos économies réelles dépendent de votre tarif négocié — calculez les chiffres avec les tarifs actuels.

Le problème de l'intégration

Voici le chiffre que la plupart des analyses développer-ou-acheter ignorent : l'intégration avec les systèmes existants consomme 60 à 70 % du temps total du projet, que vous développiez ou achetiez la plateforme PdM.

Intégration GMAO

Votre système de maintenance prédictive doit créer des ordres de travail, consulter l'historique de maintenance et mettre à jour les fiches d'actifs. Les principales plateformes GMAO ont chacune leurs propres défis d'intégration :

SAP PM : Les interfaces RFC/BAPI sont bien documentées mais complexes. La création d'une notification de maintenance (équivalent IW21) via API nécessite un mappage sur les structures de données spécifiques de SAP (emplacement technique, numéro d'équipement, codes de dommage). Prévoyez 4 à 6 semaines pour une intégration bidirectionnelle fiable.
IBM Maximo : L'API REST est moderne et bien conçue, mais le mappage des champs entre votre modèle d'actifs et la hiérarchie Maximo prend du temps. Le moteur de workflow de Maximo impose à vos ordres de travail de respecter les chaînes d'approbation existantes.
Infor EAM / Hexagon : La qualité de l'API varie considérablement selon la version. Les installations plus anciennes peuvent nécessiter un middleware personnalisé.

Intégration de l'historien

La plupart des usines disposent d'années de précieuses données de capteurs verrouillées dans un historien :

OSIsoft PI (AVEVA PI) : La PI Web API est puissante, mais requiert une configuration soigneuse de l'authentification (Kerberos ou Basic Auth). L'extraction de données historiques pour l'entraînement ML à grande échelle (millions de relevés) nécessite des requêtes par lots et une limitation du débit pour ne pas surcharger le serveur PI. Prévoyez 2 à 3 semaines.
Honeywell PHD : API plus ancienne, nécessitant souvent un serveur d'intégration sur site. L'extraction de données est plus lente qu'avec PI.
GE Proficy Historian : Interface OPC-HDA, généralement simple mais limitée à l'accès aux données en mode pull.

Intégration ERP

Pour l'approvisionnement en pièces détachées et le suivi des coûts, vous aurez besoin d'une connectivité ERP :

Intégration SAP MM pour les demandes d'achat automatisées basées sur les prédictions de RUL
Mappage des centres de coûts pour le suivi du ROI de maintenance
Synchronisation de la hiérarchie d'usine

L'implication : Que vous développiez ou achetiez le moteur PdM, prévoyez du temps et de l'expertise significatifs pour l'intégration. Une plateforme dotée de connecteurs GMAO prêts à l'emploi et de schémas d'intégration d'historiens documentés économise 3 à 6 mois par rapport à les construire de zéro.

Cadre de décision

| Facteur | Penchant Développer | Penchant Acheter | |--------|-----------|----------| | Équipe d'ingénierie des données ? | Oui, 3+ ingénieurs | Non ou < 3 | | Délai avant la première valeur ? | 6+ mois acceptables | Résultats en semaines | | Types d'actifs | 1-2 bien connus | Nombreux, équipements divers | | Infrastructure ML | Kubernetes, MLflow, etc. | En partant de zéro | | Échelle | 10 000+ actifs | 50-5 000 actifs | | Modèle budgétaire | CapEx (construire une fois) | OpEx (mensuel prévisible) |

Matrice de décision pondérée

Pour une évaluation plus structurée, attribuez un score de 1 à 5 à chaque facteur pour votre organisation :

| Facteur | Poids | Score 1 (Penchant Acheter) | Score 5 (Penchant Développer) | |---|---|---|---| | Délai avant la valeur | 25 % | Résultats en < 3 mois | 12+ mois acceptables | | Besoins de personnalisation | 20 % | Types d'équipements standard | Processus/équipements uniques | | Capacité de l'équipe | 20 % | Pas d'équipe ML/ingénierie données | Équipe ML + données expérimentée | | Sensibilité des données | 15 % | Cloud acceptable, DPA standard | Air-gapped, données classifiées | | Échelle (nombre d'actifs) | 10 % | < 500 actifs | > 5 000 actifs | | Structure budgétaire | 10 % | Préférence OpEx (mensuel) | Préférence CapEx (unique) |

Exemple concret — usine chimique de taille moyenne (300 actifs) :

Délai avant la valeur : 2 (le conseil veut des résultats ce trimestre) × 25 % = 0,50
Personnalisation : 3 (quelques réacteurs propriétaires) × 20 % = 0,60
Capacité de l'équipe : 2 (un analyste de données, sans ML) × 20 % = 0,40
Sensibilité des données : 3 (cloud standard acceptable, résidence UE exigée) × 15 % = 0,45
Échelle : 2 (300 actifs) × 10 % = 0,20
Budget : 2 (préférence OpEx) × 10 % = 0,20
Total : 2,35 → Signal fort d'achat

Un score inférieur à 2,5 oriente vers Acheter. Au-dessus de 3,5, vers Développer. Entre 2,5 et 3,5, c'est la zone Hybride.

L'option hybride

De nombreuses équipes commencent par acheter, puis construisent autour. C'est souvent le choix pragmatique — surtout dans la plage de score 2,5-3,5. Voici un calendrier par phases :

Mois 1-3 : Déployer et valider. Déployez une plateforme pour la détection immédiate des anomalies sur vos actifs les plus critiques. Utilisez cette phase pour démontrer la valeur à la direction, développer la culture données en interne et établir des métriques de référence (taux de pannes actuels, coûts d'arrêt, dépenses en pièces détachées). C'est votre phase de « victoire rapide » — n'essayez pas de tout résoudre d'un coup.

Mois 3-6 : Intégrer et étendre. Utilisez l'API de la plateforme pour intégrer les prédictions dans des tableaux de bord personnalisés et les workflows GMAO/ERP existants. Exportez des données d'entraînement pour des analyses spécialisées. Commencez à développer l'expertise interne en travaillant aux côtés des modèles de la plateforme — en comprenant ce qu'ils détectent, ce qu'ils ratent et pourquoi.

Mois 6-12 : Personnaliser et optimiser. Entraînez des modèles spécialisés pour les équipements que la plateforme gère mal (procédés propriétaires, modes de défaillance inhabituels). Construisez des intégrations personnalisées avec les systèmes hérités. À ce stade, vous disposez de 6+ mois de données étiquetées (prédictions confirmées ou corrigées par votre équipe), une ressource précieuse pour l'entraînement.

Année 2 et au-delà : Évaluer l'indépendance. Avec 12+ mois de données étiquetées, des modèles entraînés et une capacité ML interne, vous pouvez prendre une décision éclairée : continuer avec la plateforme (parce que la charge opérationnelle de votre propre solution est désormais évidente), migrer vers une solution autohébergée, ou maintenir un hybride où la plateforme gère les équipements standard et votre équipe les spécialisés.

Ce qu'il faut rechercher dans une plateforme

Pour évaluer les fournisseurs PdM, ces capacités distinguent les plateformes de qualité production des démonstrations :

Explicabilité — attribution par caractéristique (SHAP pour les modèles arborescents, Integrated Gradients pour les modèles profonds), contributions par capteur. Si le fournisseur ne peut pas expliquer ses prédictions, vous non plus ne le pourrez. Demandez-leur de montrer une alerte réelle avec attribution de caractéristiques — pas une diapositive marketing.
Multimodèle — Détection d'anomalies, estimation du RUL et classification des défauts. Une plateforme qui ne fait que la détection d'anomalies résout 30 % du problème. Vous avez besoin des trois pour passer de « quelque chose ne va pas » à « voici ce qui ne va pas et quand cela va tomber en panne ».
Gestion du cold start — Des bases préentraînées qui fonctionnent dès le premier jour, pas « attendez 6 mois d'avoir suffisamment de données ». Demandez sur quels jeux de données de référence les modèles ont été entraînés et quelle précision ils atteignent d'emblée.
Isolation des locataires — Séparation cryptographique des données. Demandez spécifiquement la sécurité au niveau des lignes versus le filtrage au niveau applicatif. Si le fournisseur dit « niveau applicatif », un seul bug peut exposer vos données à d'autres clients.
Support edge — Inférence basse latence, souveraineté des données, capacité hors ligne. Si votre site a une connectivité intermittente ou des exigences strictes de résidence des données, l'inférence en bordure n'est pas optionnelle.
Architecture API-first — Si vous ne pouvez pas l'automatiser via une API, vous en sortirez. Vérifiez que la création des ordres de travail, le statut des modèles, la gestion des alertes et l'export des données sont tous disponibles par programme.
Tarification transparente — Pas de « contactez les ventes » pour les informations de base. Tarification par actif que vous pouvez modéliser avant de signer quoi que ce soit. Les coûts cachés (dépassement de stockage, limites d'appels API, niveaux de support premium) doivent être visibles dès le départ.

Prevly propose un pilote gratuit pour jusqu'à 10 machines. Commencez ici — voyez des prédictions réelles sur vos équipements en moins d'une semaine.

Lectures complémentaires : Edge vs cloud pour la PdM · ROI de la maintenance prédictive · Maintenance prédictive vs GMAO