chronique start-ups

Il ne faut pas être à la Silicon Valley pour exceller en logiciel

École polytechnique de l'ULB

Les sociétés traditionnelles qui mettent le logiciel au centre de leur chaîne de valeur peuvent compter sur les atouts que n'ont pas les start-ups qui les concurrrencent.

À l’aube de la 5G et de l’internet des objets qui devront être programmés pour faire quelque chose, l’Europe doit s’occuper de ses logiciels. Or, elle n’a quasi aucun champion en la matière alors que les universités forment pourtant des talents. C’est que les entreprises européennes n’en font pas assez pour leurs équipes de développement. Les Chief Digital Officiers sont encore l’exception. C’est la culture industrielle qui domine toujours en interne (high tech exceptée).

Certaines sociétés rompent avec cette tradition en reprenant des start-ups pour acquérir vite et bien l’expertise manquante; les banques acquièrent ainsi les fintechs à tour de bras. D’autres mettent en place une division logicielle, la font monter et représenter au niveau exécutif pour délivrer un message stratégique à l’organisation, et elles débauchent pour recruter.

©Lieven Van Assche

Les sociétés traditionnelles qui mettent le logiciel au centre de leur chaîne de valeur peuvent compter sur les atouts que n’ont pas les start-ups qui les concurrencent: une large base de clients qui leur font confiance, un portfolio bien établi et un réseau de fournisseurs, IT ou télécoms, qui peuvent les aider dans leur transition.

Agilité

©BELGAIMAGE

Implanter une division logicielle dans une grande organisation ne suffit pas, dit McKinsey dans un rapport consacré à ce sujet. Il lui faut l’agilité. Un projet agile, c’est une équipe, petite (5 à 10 personnes) qui gère un projet qui dépend d’un chef de produit. Si ce n’est pas possible par l’ampleur du projet, il faut une organisation qui maintienne ces petites protégées et une coordination entre elles via des architectes dont ce sera le seul rôle. Ils leur épargneront d’avoir à consacrer trop de temps à communiquer, avec (les demandes) des utilisateurs finaux, les managers ou des autres équipes. Si l’entreprise doit aussi se débattre avec ses vieux logiciels qui existent depuis qu’elle existe, il lui faudra mettre en place une architecture à deux vitesses et encapsuler au plus vite ses logiciels anciens sous forme de modules aux entrées et sorties claires, utilisables ensuite comme briques stables. On parle de "sprints", explique McKinsey, pour souligner l’indépendance dont jouit l’équipe de développement pendant quelques semaines, entrecoupées de "pauses" où on prend le temps de faire le point et une démo du logiciel. On se coordonne et puis cela repart.

L’agilité impose de localiser toutes ses équipes de développement en un seul endroit: ce n’est pas pour rien que les géants d’internet ou les leaders de l’informatique ne délocalisent pas leur développement: Microsoft, c’est Seattle, Apple, Cupertino, Google, Mountain View, un point c’est tout. Bien sûr, des entreprises industrielles ne pourront pas toujours recourir à cette centralisation: les outils collaboratifs compenseront.

Les sociétés traditionnelles qui mettent le logiciel au centre de leur chaîne de valeur peuvent compter sur les atouts que n’ont pas les start-ups qui les concurrencent.

La Silicon Valley a remis l’utilisateur final au centre du développement: c’est ce qu’il veut qui compte. Cela donne un fil conducteur au projet agile qui évite de se perdre en chemin. Si le logiciel équipe des produits industriels – et l’internet des objets accélérera cette tendance, il doit être prêt plus vite pour que les ingénieurs travaillent sur le produit lui-même avec des spécifications claires, pour leur laisser le temps d’y mettre la qualité requise qui n’est pas que virtuelle.

Modularité

C’est le maître mot de projets agiles à grande échelle puisqu’elle permet de diviser le travail entre équipes de projets. Elle minimise les conflits et facilite l’intégration continue de nouveaux morceaux de code dans le produit pour le tester et l’évaluer. Pour réduire le temps d’attente dû aux interdépendances entre équipes de développements, chacune d’elles doit se concentrer sur la délivrance de nouvelles fonctionnalités pour l’utilisateur final. Une équipe de projet agile ne doit pas être en charge de délivrer un module intermédiaire sans lien avec l’utilisateur final. C’est le bon moyen de rendre impatients les autres équipes qui en dépendront. Le chef de produit gérera ensuite les tests et très vite reviendra vers les équipes de développement pour leur demander d’adapter les fonctionnalités qu’elles viennent de créer. Un développement conduit par les tests (et testeurs), c’est l’assurance d’avoir un produit bon dès le départ. Il n’est pas inhabituel de voir les plans de tests mis au point avant que les équipes de développement ne développent: penser aux tests avant, c’est être sûr que les spécifications données aux équipes sont plus claires! Les testeurs (volontaires) par millions des pre-release de Windows 10 vous le diront: ils reçoivent une mise à jour plus d’une fois par mois!

Vendeurs/fournisseurs

©REUTERS

Enfin, il ne faut pas hésiter à changer sa relation avec les fournisseurs et vendeurs qui deviennent des maillons essentiels de votre projet agile. Ne négociez pas, dit McKinsey, un contrat traditionnel aux termes inflexibles qui essaient de tout prévoir du projet à venir. Un contrat agile doit se focaliser sur le résultat à délivrer et non plus les moyens ou les équipements à livrer pour y arriver. Une gageure pour les juristes.

Si votre entreprise a pu mettre en place tout cela, l’étape suivante sera sans doute de passer au cloud pour les logiciels que vous proposez à vos clients!

Par Charles Cuvelliez
École Polytechnique de Bruxelles, ULB.

Pour en savoir plus: Software development handbook, transforming for the digital Age, McKinsey, Jan 2016.

Lire également

Messages sponsorisés

Messages sponsorisés