Chaque étape du cycle de vie d'un véhicule repose sur un logiciel différent. Les équipes de développement utilisent des plateformes de simulation. Les équipes de test utilisent des enregistreurs de données et des suites de validation. Les équipes de production effectuent des tests de fin de chaîne sur leurs propres systèmes dédiés. Les équipes du service après-vente utilisent un autre ensemble d'outils de diagnostic. Chaque équipe choisit les outils les plus adaptés à son domaine spécifique, de manière isolée.
Le problème réside dans ce qui se passe entre les étapes et d’une étape à l’autre, et non au sein même de celles-ci. Imaginez le cycle de vie traditionnel d’un véhicule comme une course de relais. Le développement passe le relais aux tests. Les tests passent le relais à la production. La production passe le relais à l’entretien. À chaque passage de relais, les connaissances doivent être réorganisées ou reconstruites. Souvent, c’est pire que cela : les outils de chaque étape ne partagent aucune connaissance ni aucun enseignement entre eux. Cela engendre trois coûts qui s’aggravent à chaque transfert :
- La charge liée à la maintenance du système se multiplie, car chaque outil supplémentaire intégré à la chaîne représente un système de plus pour lequel il faut obtenir une licence, procéder à l'intégration, appliquer des correctifs et assurer le support.
- Les coûts liés à la formation augmentent, car les nouvelles recrues et les équipes pluridisciplinaires doivent se familiariser avec un outil différent à chaque étape de leur intervention.
- Mais surtout, la continuité des connaissances est rompue. Le contexte dont disposait un ingénieur lors du développement d'une fonctionnalité n'est pas transmis de manière claire à la personne chargée de résoudre les problèmes sur le terrain six mois plus tard.
Rien de tout cela ne relève de l’échec d’une équipe en particulier. Il s’agit d’un coût structurel lié au fait de traiter la conception, le développement, les tests, la production et le support comme cinq flux de travail distincts au lieu d’un processus continu. Pour les équipementiers, ce coût se traduit par un surcroît de temps à chaque étape : un développement plus lent, des tests plus lents, des analyses de défaillance plus longues — sans compter la duplication des efforts et la perte de savoir-faire institutionnel d’une équipe à l’autre.
Ce qui rendait auparavant la réunification irréaliste
Pendant la majeure partie de l’histoire des logiciels, il n’était pas réaliste d’unifier ces outils. Les logiciels sont conçus pour des usages spécifiques. Un outil de test est conçu pour vérifier qu’un système se comporte comme prévu dans un ensemble défini de conditions, tandis qu’un outil de diagnostic sert à identifier la cause première d’un dysfonctionnement une fois que celui-ci s’est produit. Adapter l’un pour qu’il remplisse la fonction de l’autre implique de réécrire des parties substantielles du code. Si un ingénieur souhaite déplacer un bouton ou modifier un flux de travail, cela nécessite un cycle de développement.
AI commence à bouleverser cette donne, car les solutions d’ AI s autonomes à toutes ces étapes reposent de plus en plus sur les mêmes fondements. Le grand modèle linguistique (LLM) qui sous-tend un outil de test est, fondamentalement, le même que celui qui sous-tend un outil de diagnostic sur le terrain. Qu’il s’agisse d’analyser un cas de test de validation avant le lancement ou de résoudre un problème rencontré par un client après la vente, l’ AI e qui effectue le raisonnement est la même. Seul le contexte change.
Plutôt que de mettre en place un système distinct pour chaque domaine, les organisations peuvent étendre la même intelligence sous-jacente aux phases de développement, de test et de production, en l’adaptant au contexte de chaque équipe sans avoir à repartir de zéro à chaque fois. C’est le principe qui sous-tend le Sonatus Fastlane™ Platform, une plateforme d’ AI en boucle fermée qui transfère les données et les connaissances relatives aux véhicules d’une étape du cycle de vie à la suivante. Il s’agit là d’un point de départ nettement différent de ce que le secteur a connu jusqu’à présent, même si la plupart des entreprises n’en sont encore qu’aux prémices de sa mise en œuvre.
Le plus difficile, c'est l'organisation
On observe déjà les premiers signes de cette évolution dans l'ensemble du secteur, même lorsque les entreprises ne mettent en œuvre qu'une ou deux de ces mesures à l'heure actuelle :
- Intégrer plus directement les défaillances sur le terrain dans les cycles de mise à jour à distance, grâce à des « AI » embarqués tels que Sonatus Fastlane™ Edge contribuent à boucler la boucle entre le problème et le correctif déployé.
- Réutiliser les connaissances issues du service d'assistance pour définir les critères de conception et de test de la prochaine génération de modèles : c'est là qu'un outil comme Fastlane™ Insight peut transformer les résultats des diagnostics en informations exploitables pour les équipes d'ingénierie
- Utilisation des données relatives aux anomalies constatées en atelier pour comparer la qualité des pièces entre les différents fournisseurs.
- Étudier la possibilité que les données de validation issues de la phase de développement puissent être transférées avec le véhicule afin d’accélérer les diagnostics dès la mise en service, grâce aux informations contextuelles sur le véhicule fournies par l’ AI Sonatus Fastlane™ Collector.
Aucune de ces questions n'a encore trouvé de solution définitive, mais cela donne une idée de la direction que prendra le secteur lorsque les outils cesseront de se réinitialiser à chaque transfert.
Il ne s'agit pas non plus simplement de changer de logiciel. Harmoniser les outils à toutes les étapes du cycle de vie implique généralement d'harmoniser la responsabilité, le budget et les processus au sein d'équipes qui ont fonctionné de manière indépendante pendant des années. Cela pose un défi tant sur le plan de la gestion du changement que sur le plan technique. Les organisations qui considèrent cela comme une simple décision relative aux outils risquent de constater que le plus gros travail réside au niveau organisationnel.
Élaborer la stratégie d'unification
D'après mon expérience, ce type de transformation organisationnelle suit généralement quelques principes fondamentaux :
- Faire de l'unification une stratégie à l'échelle de l'entreprise. L'unification des données, des connaissances et de l'AI t doit être une directive émanant de la direction, et non un projet confié à une seule équipe.
- Désignez des référents pour chaque étape du processus. Cette initiative doit pouvoir compter sur des référents impliqués à tous les niveaux : développement, tests, fabrication et service après-vente.
- Déterminez ce qui relève du contexte partagé. Toutes les données, connaissances ou éléments ne doivent pas nécessairement transiter d'une étape à l'autre, mais les signaux pertinents, eux, doivent le faire.
- Commencez par mettre en œuvre des solutions « AI » pour un ou deux cas d’utilisation. Choisissez des cas qui tirent spécifiquement parti de la circulation bidirectionnelle des connaissances tout au long du cycle de vie, plutôt que de procéder à un déploiement complet d’un seul coup.
- Considérez les premières implémentations comme un point de départ. Tirez -en des enseignements , itérez et développez-les.
Pourquoi cela ne peut pas attendre
La pression pour remédier à ce problème ne cesse de croître. À mesure que les véhicules deviennent de plus en plus « définis par le logiciel » et que le rythme des itérations s'accélère, le coût des outils cloisonnés augmente. Chaque outil supplémentaire dédié à une étape spécifique constitue un nouveau point où le savoir-faire institutionnel se retrouve piégé, un nouveau point d'intégration à maintenir et un nouveau retard entre le moment où un problème est détecté et celui où une correction est mise en œuvre.
Pour combler cet écart, il faut utiliser les mêmes outils — ou du moins la même intelligence sous-jacente — à chaque étape. Les entreprises qui parviennent à considérer la conception, le développement, les tests, la production et le support comme un système continu unique, plutôt que comme cinq fonctions distinctes, peuvent en tirer des avantages concurrentiels structurels :
- Détecter les problèmes plus tôt, car les informations acquises à une étape sont transmises plus rapidement à l'étape suivante.
- Réduction du nombre de véhicules d'essai physiques et des efforts de validation redondants, grâce à la réutilisation des données et du contexte.
- Réduire l'écart entre un signal réel et une solution mise en œuvre.
Les obstacles techniques justifiant le maintien d’un fonctionnement en silos ont en grande partie disparu. Il ne reste plus qu’un choix stratégique : continuer à optimiser chaque étape du cycle de vie du véhicule ou commencer à considérer ce cycle de vie comme un système unique et interconnecté, fonctionnant grâce à une chaîne d’outils unifiée. Dans un secteur où le délai de mise en service (SOP) et la rapidité de résolution des problèmes deviennent de véritables facteurs de différenciation concurrentielle, ce choix ne restera pas longtemps facultatif. Les organisations qui s’y résoudront rapidement dicteront le rythme que toutes les autres seront contraintes de suivre.
Prêt à découvrir à quoi ressemble concrètement un cycle de vie connecté ? Découvrez le Sonatus Fastlane Platform pour découvrir comment les équipementiers et les fournisseurs utilisent l’ AI en boucle fermée pour accélérer leurs processus, du développement à la production et au service après-vente.