Transformation Numérique pour tous : le courage ou… la trouille
Outils numériques modernes pour tous, priorité pour l’enseignement public

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

 

DPC Ads Software Engineer Woman S 1552206Constructeur 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.

AWS Builders tools

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

Software development teamsLes 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.

Cigref nomemclature 2018 des métiersPour 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.

Outils de développement - minima communs

 

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 :

Matrice attentes outils développements

  • 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”

Logo Low code developmentLa 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.

Outils BI exemples Google et Microsoft

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.

Kissflow HP

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.

AirTable HP

 

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 :

  • DPC outils tools SS 64120784Sé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.
  • Choice AirTable KissFlowAider 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.

AdS DPC Nirvana SS 227574772Construire 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

AdS DCP Builder woman SS 52830103A 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é

Two teams developmentUne 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 !

 

Commentaires

Flux Vous pouvez suivre cette conversation en vous abonnant au flux des commentaires de cette note.

NFA

Article extrêmement intéressant !
Je me définissais moi-même jusqu'à présent comme "artisan informatique", avec toute la noblesse liée au terme d'artisan par opposition au "bricoleur", mais il est vrai que le terme de "builder" fait son effet.
J'interviens donc en tant que builder, en indépendant, pour une grande entreprise de l'industrie pharmaceutique.
Récemment, une démarche a été entreprise pour structurer l'offre interne autour de ces petites applications "low code".
Je peux compléter cet article par deux points :
_ Dans notre entreprise, la 3ème famille d'outils est basée plutôt sur ACCESS que sur Excel : des dizaines de bases Access
réalisant pour la plupart des consolidations des données des divers SI de l'entreprise, dans le but de produire des reportings ou autres
sorties diverses : envois de fichier en dehors du SI via FTP, emails, liens avec l'ERP dans certains cas.
La sécurisation de ce périmètre va passer par la mise en place d'un SGBD digne de ce nom pour héberger les données critiques
contenues dans ces bases, et également gagner en performance.
Le rôle d'ACCESS se limitera alors au requêtage, ou à la réalisation des IHM.
_ Je pense que l'avenir dans le domaine du low code est effectivement à chercher du côté des PAAS, voire maintenant HPaPAAS :
(Voir https://itsocial.fr/enjeux/cloud-computing/iaas-paas/magic-quadrant-gartner-hpapaas-high-productivity-application-paas/ )
Je m'intéresse particulièrement à la solution MENDIX, société néerlandaise leader dans le domaine, récemment rachetée par SIEMENS et également
intégrée à l'offre cloud d'SAP en tant que solution de RAD (Rapid Application Development)
Je suis étonné de voir la quasi inexistance de partenaire builder MENDIX en France, alors que la société existe depuis 2005 !
Je m'interroge sur la raison de cette absence, mais cela ne va pas m'empêcher de démarrer l'autoformation Mendix dans les jours qui viennent.

Frederic Hemmi

Vous m'avez l'air bien remonté en ce début d'année :)

Tout cela fait sens, pour y etre confronté de maniere quasi quotidienne la majorité des DSI n'a plus les moyens (et/ou la volonté) d'embaucher du personnel pour ces projets. Comme vous le dites, le modèle actuel est 1 chef de projet coté client et une ESN qui délivre le projet.

Puisque le budget existe ca devrait etre qu'une question d'arbitrage budgetaire (le cout d'un projet d'une dizaine de semaines est parfois supérieur a l'embauche sur une année des memes consultants) Mais ce n'est pas le cas.

Ce modele est en place a cause du risque perçu et également au mode de validation interne de ces projets et des budgets relatifs plus facile a obtenir que l'embauche d'une équipe en CDI.

Sans partir dans trop de details il faudrait un nouveau modele, une nouvelle approche de ce coté la aussi avant de pouvoir envisager de tels changement et c'est plus du coté du cfo que la reponse est comme souvent...

Louis Nauges

Nous sommes en phase sur l'essentiel, à mon avis.
Vous citez d'autres offres de développement "Low Code" et c'est très bien.
Une fois de plus, l'offre n'est plus le problème: c'est dans la volonté des entreprises de mettre en œuvre ces démarches de développement qui reste sur le chemin critique.

Louis Nauges

Oui, j'ai beaucoup d'énergie et espère garder longtemps ma capacité à... m'indigner !

Si les entreprises étaient rationnelles dans leurs décisions financières, il y a longtemps que la réinternalisation des développements serait une réalité.

Dans une véritable démarche de Transformation Numérique, les développements en interne, professionnels et "low code", sont des briques essentielles, permettant de reprendre la main sur leurs applications et en plus, en dépensant beaucoup moins d'argent.

Frederic Hemmi

Il y a un facteur irrationnel c'est clair mais lequel? La peur d'embaucher en CDI? Le fait qu'il est plus facile d'externaliser (et blamer l'ESN si ca tourne mal?)
Je serais curieux d'avoir votre avis la dessus.

Louis Nauges

@Frédéric
Il n'y a rien d'irrationnel derrière cette décision de tuer les équipes internes de développement.
C'était lié à la croyance naïve des DG et des DSI que tout le SI pouvait être acheté ou paramétré avec des ERP, et l'aide, intéressée, des ESN.

La dimension financière n'intervenait pas : on comparait les "taux jours" de différentes ESN, mais jamais avec les coûts de véritables développements en interne.

Mon combat, depuis quelques années, c'est pour la reconnaissance de l'importance de reprendre le contrôle, la maîtrise de ses usages cœur métier, et la seule manière d'y arriver, c'est avec des équipes de "builders" en interne.

Cela demande un changement total de vision de la part des DG et des DSI ; c'est tout sauf facile !

melbin

Bonjour, selon mon expérience il y a un peu des 2. Mais le prépondérant est surtout le faite de l'effet parapluie : "on ne peut rien me reprocher, j'ai fait tout ce qui était en mon pouvoir pour que ca se passe bien : regardez j'ai pris le meilleur prestataire de la place, si ca ne se passe pas bien je ne suis pas responsable !". J'entends ca à toutes les sauces... et le corollaire schizophrène aussi d’ailleurs : on ne retient jamais les idées des gens en interne, par contre la même idée énoncée par un prestataire est toujours géniale.....

Frederic Hemmi

Merci pour votre reponse
Et les éditeurs les ont bien aidé a y croire en promettant qu'avec le SaaS plus besoin de dévelopeur / builder
Je vois fleurir des ''business owner'' (des personnes venu du metier qui en plus de leur job tente de faire de la MOA avec plus ou moins de réussite) mais pas de builder a l'horizon, en espérant que ca change

Frederic Hemmi

Oui et j'ajouterais l'ESN qui se défausse sur l'éditeur lorsque ca tourne mal

Louis Nauges

@ Melbin & Frédéric

Cette fuite face aux responsabilités est une réalité.
On rejoint le thème que j'avais abordé dans mon billet précédent sur le courage ou la trouille.

Les DSI et les DG doivent réinternaliser rapidement les développements et prendre la responsabilité, non seulement de la construction (builder) mais aussi de la continuité de fonctionnement de ces application pendant de nombreuses années.

NFA

Je vois que personne ne parle de performance...
Même si nos fichiers XLS sont sur le cloud, et que l'on peut donc utiliser Excel dans le navigateur, je réouvre systématiquement le "client lourd" dès qu'il faut faire du vrai travail.
La couche web induit toujours des lenteurs, l'expérience utilisateur sera toujours plus agréable sur un outil installé en local, vous ne croyez pas ?

Louis Nauges

@NFA
Réponse simple : le client lourd n'est plus nécessaire et va disparaître, rapidement.

Regardez la conférence de lancement de STADIA, la nouvelle plateforme de streaming de jeux vidéos de Google :

https://www.youtube.com/watch?v=nUih5C5rOrA&t=3211s

Difficile d'imaginer un usage qui demande plus de performance ! Tout sera disponible, en 2020, dans un... navigateur.

Autre exemple : les "builders" travaillent de plus en plus en direct dans le Cloud.

Autre avantage : en travaillant sur le Cloud, en mode collaboratif natif, et contrairement aux idées reçues, on réduit fortement la consommation de bande passante dans les réseaux car il n'est plus nécessaire de faire circuler des fichiers de dizaines de Mo entre les participants.
Ils ont tous, en permanence, accès à la dernière version à jour.

Je le rappelle : il ne s'agit pas d'utiliser Excel ou tout autre outil paléontologique dans le cloud, il s'agit d'utiliser des outils "Natifs Clouds".

Résumé : hors du navigateur, pas de salut !

NFA

Malgré toute votre expertise et expérience, je m'indigne à mon tour sur ce credo 100% bureautique dans le cloud.
Parlez avec des gens qui utilisent ces outils tous les jours, en les poussant dans leur retranchements : ils ne tiendront pas 1H dans un navigateur.
Pour que l'avenir puisse vous donner raison, il faudrait que les performances des tableurs cloud soient équivalentes à Excel, et c'est encore loin d'être le cas.

Louis Nauges

@NFA
Cela fait 12 ans que des millions de personnes, dont je fais partie, utilise quotidiennement des outils bureautiques, mail, agenda, texte... dans leur navigateur.

Concernant les tableurs, vous n'avez manifestement pas utilisé G Sheets depuis longtemps ; plus de 80% des fonctionnalités d'Excel y sont disponibles.

Je l'ai écrit souvent : les tableurs clouds sont largement au niveau des tableurs historiques tels qu'Excel.
Concernant les "applications Excel", elles sont néfastes, fausses et dangereuses. Il existe d'excellentes applications Cloud pour les remplacer, tels que AirTable.

Libre à vous de continuer dans vos certitudes du début des années 2000.
Bientôt, vous vous sentirez bien seul...

L'utilisation des commentaires est désactivée pour cette note.