Des équipes internes de constructeurs de logiciels, de “Builders” : indispensable et urgent

 

Constructeur de logiciels, c’est probablement le plus beau métier dans le monde du numérique.

Ce sont les personnes qui construisent des produits et services utilisés par des milliards de personnes, tous les jours.

Le vocabulaire a beaucoup évolué depuis les débuts de l’informatique : programmeur, développeur puis ingénieur logiciel.

Depuis peu apparaît l’expression “Builders”, constructeurs, que j’aime beaucoup. Les grands acteurs du cloud emploient de plus en plus cette expression, comme le montrent ces deux extraits de la conférence introductive du CEO d’AWS, Andy Jassy lors de la réunion “Re-invent” de novembre 2018.

Aujourd’hui, ces “ingénieurs logiciels” sont employés en priorité par les éditeurs de logiciels, grand public et professionnels.

Les entreprises innovantes ont compris, récemment, qu’il est urgent de reconstruire en interne des équipes de “Builders” de logiciels. Toutes les entreprises, et en priorité les plus grandes, doivent suivre leur exemple, embaucher et former des milliers de constructeurs de logiciels.

Une priorité de plus, pour 2019.

 

Situation actuelle : une catastrophe absolue, dangereuse, intenable

Les entreprises, et en particulier les plus grandes, ont commis depuis une vingtaine d’années une faute majeure, en supprimant les équipes internes de développement.

Le mythe de l’ERP intégré, capable de tout faire y est pour beaucoup, aidé en cela par les grandes ESN qui déploient des équipes de plusieurs dizaines de personnes pour les “paramétrer” dans des missions qui ne finissent jamais. C’est une poule aux œufs d’or qu’elles n’ont aucun intérêt à tuer...

Je croise tous les jours de grandes entreprises où il n’y a plus une seule personne qui écrit du code pour une application sur mesure ! Des “chefs de projets” gèrent, avec un outil très “puissant et professionnel”, Excel, les prestataires qui exécutent ces travaux de développement, le plus souvent dans des pays lointains tels que l’Inde.

Pour mesurer l’étendue de ce désastre, il suffit de consulter la “bible” de l’emploi des informaticiens dans les entreprises, le document publié par le Cigref (Club Informatique des Grandes Entreprises Françaises), la nomenclature des métiers du Système d’Information.

Dans ce long document de 193 pages, mis à jour en 2018, où tous les métiers sont censés être cités, j’ai recherché l’occurrence de quelques mots importants, liés aux développements modernes tels que :

• Devops
• Microservices
• Serverless
• Container
• Ingénieur logiciel

Ils brillent tous par leur absence : aucun n’est cité, même une seule fois !

J’ai identifié les deux seuls métiers qui parlent de développement :

• 3.2. Concepteur - Développeur : que trouve-t-on comme compétence nécessaire ? “Adapte et paramètre les progiciels applicatifs (ERP)” ! La messe est dite…
• 3.5. Paramétreur de progiciels : dans ce deuxième cas, c’est encore plus clair !

Ce qui me navre, ce qui me désespère, c’est que ce document représente un travail long et sérieux, par de personnes occupant des postes élevés dans les DSI de grandes entreprises françaises. Il est un reflet précis de la vision actuelle de ces entreprises et confirme que pour elles, les véritables métiers du développement… n’ont pas droit de cité chez elles.

Optimiste de nature, je me prends à rêver, à ouvrir la version 2019 de ce document et y découvrir... au moins trois définitions de fonctions liées à des métiers de constructeur professionnel de logiciels.

 

Deux grandes familles de demandes, donc... d’outils

Démarrée il y a 20 ans, la révolution des solutions logicielles SaaS, Software as a Service, a permis de répondre à 99 % des attentes des entreprises pour les fonctions S, Support, du modèle B I S que je propose depuis 2015.

C’est une excellente nouvelle : cela libère du temps et des ressources pour investir dans des développements spécifiques pour les fonctions B, Business ou cœur métier.

Une fois de plus, l’unicité des réponses est le plus grand danger : pour répondre à des demandes spécifiques très différentes, il faut proposer des solutions… très différentes.

Solutions de développement : minima communs

Tous les outils utilisés pour développer des applications spécifiques ont les caractéristiques communes suivantes :

• Disponibles dans des clouds publics industriels : en pratique, sur AWS d’Amazon, GCP de Google ou Azure de Microsoft.
• Accessibles depuis un navigateur et sur tous les objets d’accès du marché, depuis les smartphones jusqu’aux Chromebooks.
• Fonctionnent dans une logique collaborative native, pour permettre le partage des applications qui seront construites.

 

Matrice des attentes et des outils

Attentes et outils peuvent être classés en deux grandes familles, ce qui permet de construire une matrice à 4 cases :

• Attentes structurées et complexes : les usages cœur métier d’une entreprise sont dans cette famille : gestion des infrastructures de transport dans une ville, équilibrage de l’offre et de la demande d’électricité…
• Attentes flexibles et légères : tableaux de bord pour suivre le lancement d’un nouveau produit, processus d’embauche d’un nouveau salarié…
• Outils industriels de développement : solutions Serverless, microservices...
• Outils “Low Code” de développement : Business Intelligence, Business Process Management...

Il est important de le préciser : il n’y a pas une famille plus “noble” que l’autre. Il ne faut pas opposer les développeurs “pros” qui maîtrisent les outils industriels aux bricoleurs qui utilisent les outils légers. Ils ont tous des rôles essentiels dans la réussite de la Transformation Numérique d’une entreprise.

 

Attentes légères, outils “Low Code”

La demande d’applications légères, flexibles, faciles à modifier est universelle. Quand une DSI n’a pas de réponse à ces demandes, quand elle ne trouve ni le temps ni les ressources pour y répondre, on assiste à l’explosion des informatiques fantômes et du cloud fantôme.

Il est urgent de recréer une confiance réciproque entre la DSI et les métiers pour que, ensemble, il soit possible de construire ces centaines d’applications légères.

Avec la banalisation du cloud public et des solutions SaaS, l’offre d’outils performants “Low Code” est devenue très riche et d’une exceptionnelle qualité.

L’expression “Low Code” semble s’imposer face à “Zéro Code” : elle correspond mieux à la réalité et ne crée pas de fausses attentes auprès des personnes qui pourraient penser que l’on peut construire des applications avec “zéro effort”.

Principales familles d’outils “Low Code”

Le regroupement de ces outils en trois familles que je propose est pragmatique, probablement incomplet et contestable.

Business Intelligence : ce sont des outils qui permettent de construire des tableaux de bord, des visualisations de résultats. Face aux solutions anciennes, complexes et chères, de nouveaux entrants comme Google Data Studio ou Power BI de Microsoft représentent l’avenir de cette famille d’outils.

BPM : Business Process Management. Pour construire des “workflows”, des processus légers, une solution comme RunMyProcess, développée par des Français et rachetée par Fujitsu ou Kissflow sont de bons exemples de solutions performantes.

Remplacement des applications Excel : je ne connais pas d’entreprises où des dizaines, des centaines ou des milliers d’applications Excel ne soient pas omniprésentes. J’ai souvent critiqué ces applications, mal écrites, avec des erreurs de logique dans presque 70% des cas. La bonne nouvelle, aujourd’hui, c’est que de nouveaux outils, 100 % Cloud, permettent de construire des applications de remplacement, plus performantes, plus faciles à développer et… partageables. Le nouveau leader dans ce domaine a pour nom AirTable.

 

DSI : quels rôles pour outils “Low Code”

Laisser les directions métiers et les collaborateurs de l’entreprise seuls avec ces outils “Low Code” est une très mauvaise idée ! Les équipes de la DSI doivent être capables de les prendre en charge pour permettre une collaboration efficace avec les métiers.

Les compétences les équipes de la DSI dans ce domaine :

• Sélectionner les différents outils : elles vérifient que ce sont de véritables outils SaaS et proposent des solutions adaptées aux différentes demandes, en en limitant raisonnablement le nombre. Il n’est pas nécessaire de pousser deux solutions de BI qui font à peu près la même chose ! Les entreprises qui utilisent G Suite choisiront Google Data Studio, celles qui ont déployé Office 365, Power BI.
• Maîtriser et connaître les outils sélectionnés : il ne suffit pas d’en parler aux métiers, il faut être capable de présenter concrètement les fonctionnalités de ces différents outils et de les aider à en comprendre les potentiels et les limites.
• Pouvoir développer des applications légères : les équipes “Low Code” de la DSI réalisent des développements légers si les métiers le demandent. Quel pourcentage des usages légers sera réalisé par la DSI, quel pourcentage par les métiers ? Les réponses seront très différentes selon les entreprises.
• Aider dans le choix de l’outil le mieux adapté à une demande : il ne sera pas toujours facile ou évident de choisir un outil pour répondre à une demande précise. KissFlow ou Airtable ? Dans de nombreux cas, les deux réponses sont possibles : DSI et métiers choisiront, ensemble, la réponse qui leur paraît la plus raisonnable.
• Former des personnes dans les métiers pour qu’ils construisent eux-mêmes tout ou partie des applications dont ils ont besoin. Quand les métiers sont prêts à se prendre en main sur certains de ces outils, la DSI peut leur mettre le pied à l’étrier.

Avec des outils de construction “Low Code” bien choisis et maîtrisés, tout le monde sera gagnant, l’entreprise, les métiers et la DSI.

 

Attentes structurées, outils industriels

Rappel : seules les fonctions B, cœur métier, sont concernées par des développements structurés sur mesure, si des solutions SaaS verticales ne sont pas disponibles pour ces métiers.

Il existe dans toutes les entreprises grandes ou moyennes, des attentes cœur métier pour lesquelles on ne trouve pas d’applications SaaS ou on souhaite construire une application différente, innovante et porteuse de compétitivité.

Il ne devrait plus venir à l’esprit d’un dirigeant ou d’un DSI l’idée saugrenue d’essayer de modifier un ERP non adapté pour répondre à ces attentes. La seule réponse moderne est de… construire une application sur mesure.

Des outils industriels modernes, très puissants

Nous sommes en 2019 ! L’offre d’outils de construction d’applications structurées n’a plus rien à voir avec celles que connaissaient les développeurs il y a encore 5 ans.

Construire des applications, aujourd’hui, c’est le “Nirvana” pour les “builders” !

Les fondamentaux de l’offre :

• Disponibles dans des clouds publics ou… des clouds publics, AWS, GCP ou Azure.
• Serverless : Lambda chez AWS, Functions chez Azure ou GCP permettent aux constructeurs d’applications de se concentrer sur le code, rien que sur le code, et de ne plus se préoccuper des infrastructures sous-jacentes.
• Microservices : de petites équipes de constructeurs (les célèbres “two pizza teams” chères à Amazon) travaillent dans une logique de composants définis par leurs “API” d’entrée et de sortie.
• Devops : chaque équipe est responsable de la construction de ses composants, de la mise en production et de la maintenance.
• Containers : masqués aux développeurs, ces composants s’exécutent dans des containers.
• Open Source : la majorité des technologies d’infrastructures et de constructions s’appuient sur des solutions Open Source : Docker, Kubernetes, Istio…

Des équipes internes, sous la responsabilité de la DSI

A l’inverse de ce qui peut se faire pour les outils de constructions légers, les constructions d’applications structurées doivent rester à 100 % sous la responsabilité de la DSI. Ce serait une très mauvaise idée de laisser croire aux métiers qu’ils pourraient les construire eux-mêmes. Nous sommes nombreux à savoir conduire une voiture, beaucoup moins à savoir piloter un Airbus 320.

S’agissant d’applications cœur métier essentielles pour les entreprises, la majorité des constructeurs de ces applications sont des collaborateurs internes et permanents de l’entreprise. Il serait suicidaire de confier la maîtrise de ces constructions à des ESN !

 

Ces équipes internes de “builders” ont une triple compétence :

• Maîtriser les démarches modernes et les outils de constructions cités plus haut.
• Une compréhension raisonnable des activités de leur entreprise, pour être capables de dialoguer efficacement avec les métiers. Dans les grandes entreprises, cela signifie qu’il faudra des équipes spécialisées par grands métiers, pour plus d’efficacité.
• La capacité de travailler dans une logique “produit”, et non pas projet. La pérennité de ces produits logiciels est vitale ; elle inclut leur maintenance et leur évolution pour garantir qu’ils restent pertinents pendant plusieurs années.

Et si la DSI redevenait ce qu’elle n’aurait jamais dû cesser d’être : un lieu où les constructeurs, les réalisateurs sont plus nombreux et mieux considérés que les “managers”, les chefs de projets ?

 

Résumé

Une entreprise qui ne dispose pas en interne de deux équipes de constructeurs de logiciels, pour réaliser aussi bien des applications légères avec des outils “Low Code” que des applications structurées avec des outils industriels est incapable de répondre aux attentes de tous ses clients internes et externes.

 

Quelle taille pour ces deux équipes de constructeurs ? Je vous propose un objectif minimum de… 20 % du nombre de collaborateurs permanents de la DSI !

Dirigeants et DSI, vous devez investir immédiatement et massivement pour créer ces équipes, les former, leur proposer des plans de carrière attractifs pour qu’une personne puisse dire : “j’ai 50 ans, je suis fier de mon métier de constructeur de logiciels et… je gagne très bien ma vie.”

Un beau défi de plus pour les entreprises courageuses et innovantes !