L'actualité récente du secteur automobile met en lumière un défi qui concerne tous les développeurs de logiciels embarqués.
Une histoire L'accent a été mis sur la décision de Ford de faire revenir des ingénieurs expérimentés, reconnaissant ainsi l'importance du savoir-faire institutionnel. Les personnes qui comprennent pourquoi les systèmes ont été conçus d'une certaine manière, comment ils ont évolué et où se cachent les risques potentiels sont souvent tout aussi précieuses que la technologie elle-même.
Une autre histoire L'affaire Polestar, interdite de vente de véhicules aux États-Unis en raison de matériels et de logiciels liés à la Chine et à la Russie, met en lumière une réalité de plus en plus importante : l'origine, la propriété et la gouvernance des logiciels deviennent des enjeux stratégiques, indépendamment de la position des entreprises sur ces questions politiques sous-jacentes.
À première vue, ces deux histoires semblent sans lien. L'une concerne les personnes, l'autre la technologie. Mais au fond, elles traitent toutes deux de la même chose : la capacité d'une organisation à garantir la fiabilité des systèmes dont elle dépend – qui les a construits, qui les maîtrise actuellement et qui en sera responsable à l'avenir.
Ces articles soulèvent finalement les mêmes questions :
Qui est à l'origine de ce code ?
Pas seulement qui l'a écrit.
Qui le comprend ?
Qui s'en occupe ?
Qui en est le propriétaire?
Qui peut l'expliquer ?
Et qui continuera à le soutenir des années après le lancement du produit ?
Ce sont des questions que tout constructeur automobile devrait se poser. Ce sont également des questions que les fabricants de dispositifs médicaux, d'équipements industriels, de produits de fitness et d'électronique grand public devraient se poser.
Car la provenance des logiciels n'est plus seulement une préoccupation informatique.
C'est une affaire commerciale.
La chaîne d'approvisionnement des logiciels se complexifie
Il y a quelques années encore, l'évaluation des logiciels était relativement simple. Les entreprises se concentraient sur les fonctionnalités, les performances, le coût et les délais de livraison.
Aujourd'hui, les entreprises, soucieuses d'accélérer les cycles de développement, ont changé la donne.
Les logiciels peuvent être développés dans plusieurs pays. Leurs composants peuvent provenir de nombreux fournisseurs. Les bibliothèques open source sont intégrées aux applications modernes. Les outils de développement assistés par l'IA génèrent du code à une vitesse sans précédent. Les équipes évoluent. Les prestataires changent de projet. Des acquisitions ont lieu. Les feuilles de route des produits sont modifiées.
De ce fait, de nombreuses organisations peuvent expliquer ce que fait leur logiciel. Rares sont celles qui peuvent expliquer avec certitude d'où il provient.
Cette distinction est importante.
Qu’il s’agisse de concevoir un cockpit numérique, un dispositif de surveillance médicale, un tapis roulant connecté, un appareil électroménager intelligent ou un panneau de commande industriel, le logiciel qui sous-tend l’expérience utilisateur représente une part de plus en plus importante de la valeur du produit – et de son risque.
Trois questions que tout fabricant devrait se poser
Question 1 : Savez-vous où votre logiciel est développé ?
Pendant des années, l'origine des logiciels a été largement considérée comme une question d'approvisionnement.
Aujourd'hui, cela devient un problème de gouvernance.
L'industrie automobile en ressent déjà les effets, les autorités réglementaires examinant de plus près les technologies des véhicules connectés et les écosystèmes logiciels qui les sous-tendent.
La géographie est importante, surtout avec l'évolution de la réglementation. Les fabricants doivent avoir une visibilité sur le lieu de développement du logiciel, les propriétaires de la propriété intellectuelle, les responsables de la feuille de route, les personnes en charge de la maintenance des composants critiques et les dépendances au sein de la pile logicielle.
La transparence devient un avantage concurrentiel de plus en plus important. Non pas parce que la réglementation l'exige, mais parce que les équipes dirigeantes, les clients et les parties prenantes l'attendent.
Question 2 : Savez-vous quelle proportion de vos logiciels a été créée par l'IA ?
L'IA transforme rapidement le développement logiciel.
Utilisés de manière responsable, les outils basés sur l'IA peuvent améliorer la productivité, réduire les délais de développement et aider les ingénieurs à résoudre les problèmes plus efficacement.
Mais l'essor du code généré par l'IA soulève de nouvelles questions. Qui l'a examiné ? Qui l'a validé ? Qui en est responsable ? Et lorsqu'un problème critique surviendra des années plus tard, qui sera disponible pour l'expliquer, le maintenir et le corriger ?
La question n'est pas de savoir s'il faut utiliser l'IA. Le problème est de savoir si les organisations conservent la responsabilité technique des développements réalisés : cela peut impliquer la validation de chaque modification apportée par l'IA par un ingénieur désigné, une norme de revue documentée avant la mise en production du code, ou simplement une politique exigeant qu'aucun composant généré par l'IA ne soit déployé sans qu'une personne puisse en expliquer le fonctionnement.
Que le code soit écrit par une personne, généré par un outil ou créé par une combinaison des deux, la responsabilité ne peut être déléguée. Il faut toujours que quelqu'un le comprenne.
Surtout pour les produits dont les clients dépendent au quotidien.
Question 3 : Ce savoir appartient-il encore à quelqu'un ?
Il s'agit peut-être de la question la plus négligée de toutes.
L'histoire de Ford Ce sujet a trouvé un écho favorable car toutes les entreprises d'ingénierie sont conscientes de ce problème. Au fil du temps, les compétences se perdent. Les projets changent de mains. Les équipes se réorganisent. Les fournisseurs évoluent. La documentation devient obsolète.
À terme, les organisations peuvent se retrouver responsables de systèmes que personne ne comprend pleinement.
Ce n'est pas un problème technologique, mais un problème de connaissances. Et c'est l'une des raisons pour lesquelles les partenariats à long terme sont importants.
Les fabricants ont besoin de bien plus que du code source. Ils ont besoin d'un accès à l'expertise. Ils ont besoin de continuité. Ils ont besoin de partenaires qui comprennent non seulement ce que fait le logiciel, mais aussi pourquoi il a été conçu ainsi à l'origine, et qui peuvent encore expliquer et soutenir ces décisions des années plus tard.
De meilleures questions mènent à de meilleurs produits
À mesure que les produits deviennent plus connectés, plus intelligents et plus pilotés par logiciel, les fabricants devraient interroger leurs partenaires technologiques sur quelques questions fondamentales :
- Où ce logiciel a-t-il été développé ?
- Qui en est le propriétaire?
- Qui s'en occupe ?
- Comment l'IA est-elle utilisée dans le processus de développement ?
- Qui comprend l'architecture ?
- Qui assurera le support de ce produit dans cinq ou dix ans ?
Ce ne sont pas seulement des questions d'ingénierie.
Ce sont des questions de leadership.
Ce sont des questions qui portent sur la capacité d'une organisation à garantir avec confiance les produits qu'elle met sur le marché, aujourd'hui et dans les années à venir.
Ce sont des questions relatives au risque, à la résilience, à la responsabilité et au succès à long terme du produit.
Pourquoi Altia
Chez Altia, ces questions ne sont pas théoriques.
Nous développons des logiciels pour interfaces graphiques embarquées depuis 1991. Nos équipes d'ingénierie sont basées aux États-Unis et en Europe, et nos ingénieurs travaillent chez nous depuis plus de 15 ans en moyenne. Cela signifie que les personnes qui ont conçu votre logiciel sont très probablement les mêmes qui peuvent encore vous expliquer pourquoi il a été développé de cette manière.
Cette continuité est importante.
Nombre de nos clients font confiance à la technologie d'Altia depuis plus de dix ans. Ces relations durables témoignent de ce qui se produit lorsqu'un fournisseur considère la maintenance et le support à long terme comme une fonctionnalité à part entière de son produit, et non comme une simple option.
Notre équipe possède une expertise pointue en graphisme embarqué, interfaces homme-machine, optimisation des performances, déploiement en production et support produit à long terme. De même, nous accordons une grande importance à la transparence quant au développement de nos logiciels, aux personnes qui assurent leur support et à leur évolution.
Dans un monde où les chaînes d'approvisionnement logicielles sont de plus en plus complexes, où la surveillance réglementaire s'intensifie, où le code est généré par l'IA et où les technologies évoluent rapidement, nos clients méritent d'avoir confiance dans les personnes, les processus et l'expertise qui sous-tendent nos produits.
Les organisations qui conçoivent les produits de demain — qu'il s'agisse de véhicules, de dispositifs médicaux, d'équipements de fitness, de systèmes industriels ou d'électronique grand public — devraient savoir d'où proviennent leurs logiciels, qui les soutient et qui sera là pour les prendre en charge à l'avenir.
Ce sont le genre de questions qui permettent de concevoir de meilleurs produits et de nouer des partenariats plus solides.