Podcast: Play in new window | Download (Duration: 26:36 — 8.9MB)
Subscribe: Apple Podcasts | Spotify | Android | Blubrry | Email | RSS | More
L’informatique du futur appartiendra aux développeurs full-stack m’a expliqué Hervé Rincent, développeur indépendant. Malgré les conclusions parfois hâtives de certains gourous de la technologie, les techniques low-code no-code ne feront pas, selon l’expert IT, disparaître les développeurs, pas plus qu’ils n’ont été tués par la généralisation des ERP. Voyons ici avec Hervé, comment nous pourrions envisager d’imaginer le futur de l’informatique. Un futur où les informaticiens seront forcément, selon lui, des développeurs full-stack capables de comprendre le métier du client et de travailler en symbiose avec lui.
Le futur de l’informatique appartiendra aux développeurs full-stack
Où va l’informatique et quel avenir pour les informaticiens
Où va l’informatique ? Les innovations technologiques foisonnantes nous font parfois perdre de vue la réalité du terrain. La vague low-code no-code va-t-elle renverser tous les codeurs sur son passage ? Et quel est l’avenir de l’informatique et des développeurs ? Devront-ils apprendre le métier de leurs clients (internes et externes) ?
Pour en débattre, j’ai invité Hervé Rincent, dont la société Camilab.co fait du développement sur mesure, et qui publie un article de blog sur l’IT toutes les semaines que l’on retrouve dans une newsletter que je ne manque jamais de lire.
Dans cette interview, résumée dans ce billet, nous nous sommes efforcés d’envisager le futur de l’informatique.
Des organisations floues auxquelles plus personne ne comprend rien
Avant de faire de l’informatique, il faut cartographier les organisations et les processus. Cela a même été mon métier pendant de nombreuses années.
Or, les organisations sont, selon Hervé, génératrices de flou.
Il y a un effet « des concepts mal définis, des frontières mal dessinées, des abus de vocabulaire où tout le monde utilise le même mot pour désigner des choses qui sont différentes, c’est cette complexité, qu’on appelle souvent la complexité accidentelle, qu’on va retrouver dans son code si on n’y prend pas garde » explique-t-il.
La plus-value du développeur va être de rendre explicite ce qui ne l’est pas
Il faut éviter que ces flottements, ces imprécisions de vocabulaire, ces concepts mal définis se retrouvent dans le code. C’est ce manque de clarification qui est à l’origine de la fameuse analogie du SI et du plat de Spaghetti
Les entreprises n’ont jamais eu autant besoin de développeurs
On entend parfois dire que le métier de développeur est en voie d’extinction, que le no-code va remplacer les codeurs. Mais il n’en est rien.
« Quand je discute avec les entreprises, je constate exactement l’inverse », souligne Hervé.
Il identifie même trois cas de figure qui justifient l’appel à un développeur :
- Les entreprises qui n’ont ni ressources ni moyens et qui se débattent avec des milliers de fichiers Excel, en maintenant seules leur IT. Celles-ci arrivent à la limite de ce qu’elles peuvent faire avec Excel, car plus personne n’arrive à utiliser ces fichiers devenus trop lourds, sur lesquels on ne peut pas aisément, travailler à plusieurs ;
- Les entreprises qui ont fait le choix d’un SaaS intégré ou d’un énorme ERP qui fait tout. Le problème est que 99 % des fonctions que l’outil propose ne sont pas utiles à l’entreprise. Les fonctionnalités phares se retrouvent noyées dans la masse. Les utilisateurs font ainsi face à un logiciel extrêmement complexe, à utiliser juste pour 1 % des fonctionnalités dont ils ont besoin. De plus, la tarification de ces outils par utilisateur grimpe vite quand l’organisation commence à prendre de l’ampleur ;
- Les entreprises qui ont fait le choix d’utiliser des SaaS plus simples, spécialisés par domaines. Certaines utilisent 5, 10, 15 ou 20 outils différents, qui ne communiquent pas entre eux. Ces outils sont souvent simples à utiliser, mais les utilisateurs passent leur temps à faire des copier-coller de données d’un outil vers un autre parce que ces applications SaaS sont cloisonnées.
Sur la base de ce bilan, beaucoup d’entreprises commencent à faire l’évaluation du coût d’un développement sur mesure.
Le sur-mesure n’est pas forcément ruineux
Celui-ci répondrait explicitement et expressément à leurs besoins, ferait gagner du temps à leurs utilisateurs, sans les noyer sous des fonctionnalités, sans connaître les limites d’Excel, et sans demander aux utilisateurs de passer leur temps à faire des copier-coller.
« Elles s’interrogent sur la pertinence de l’open source, d’autant plus que les techniques de développement logiciel ont beaucoup évolué et qu’on ne part jamais de zéro quand on code », explique Hervé Rincent.
Plus les progiciels sont disponibles et universels, moins on réussit à tuer le spécifique
Un de mes amis qui était conseiller du patron d’une ESN m’a confié un jour que la France était le pays le mieux équipé en sociétés de services en informatique par tête d’habitant tant nous avions un amour immodéré des logiciels spécifiques.
Or les grands progiciels et logiciels verticaux n’arrivent toujours pas à venir à bout des logiciels spécifiques. Peut-être même qu’ils ont un effet repoussoir…
« Les grands acteurs ou les gens qui font des logiciels en SaaS ont un objectif en tête », m’a confié Hervé, « ajouter des fonctionnalités pour élargir leurs parts de marchéLa part de marché (PDM) peut être définie comme un pourcentage exprimant la place qu’occupe un producteur ou une marque donnée sur son marché et conquérir de nouveaux utilisateurs ». « Leurs métriques sont le nombre d’utilisateurs, et le nombre d’utilisateurs pérennes ».
Leur objectif est d’élargir petit à petit cette palette des fonctionnalités pour plaire au plus grand nombre et avoir un grand nombre d’utilisateurs.
« Tous ceux qui ont essayé d’utiliser Salesforce voient dans quelle complexité accidentelle on est tombé : il faut payer des consultants à 1 000 € la journée pour arriver à configurer son Salesforce, pour arriver à faire son job, avec un outil dont on n’utilise pas 99 % des fonctionnalités, et dont la tarification par utilisateur est loin d’être donnée », constate-t-il.
Si on additionne le consulting nécessaire à configurer son instance et le coût d’utilisation mensuel par utilisateur, la comparaison avec le spécifique n’est donc pas forcément en faveur du logiciel sur étagère, explique Hervé Rincent.
En regard, il y a un développement spécifique maîtrisé par l’entreprise, avec lequel on va pouvoir fabriquer un logiciel qui embarque vraiment sa spécificité et son cœur de métier.
Finalement, l’option du logiciel spécifique n’est peut-être pas aussi insensée qu’on veut bien le dire. Nicholas Carr pourra repartir à l’école.
Low code – No code: le retour des langages de quatrième génération
Le monde moderne aimant essayer de tuer tout ce qu’il peut, il n’est nulle surprise qu’on annonce la mort du code grâce à l’avènement du low-code, no-code.
Mais comme toujours, la réalité dépasse la fiction et elle est surtout plus complexe.
« Dans les outils no code en réalité on code, mais avec un niveau d’abstraction différent. On ne code pas dans un langage, mais en déplaçant des objets sur un écran, en mettant des widgets qu’on va relier » explique Hervé Rincent.
[NDLR Pour nos jeunes lecteurs, j’ai assisté à une des premières démonstrations d’un atelier de génie logiciel graphique Xerox dans les années 1980 (sic !)]
« Des outils no code comme Bubble par exemple, demandent du temps et de bien connaître l’outil. Il y a 27000 possibilités de configuration quand on déplace des widgets, par exemple. L’expérience de cet outil est très proche de l’expérience de codage » ajoute Hervé Rincent.
Mais à la différence du vrai code où on est propriétaire du code source, le code réalisé avec un outil no code est propriétaire de la plateforme no code. Une nuance de poids.
Changer d’outil ultérieurement devient également impossible « parce que le code réalisé et la logique métier sont attachés à l’environnement de l’outil no-code propriétaire ».
On perd une marge de liberté, et parfois on ne gagne pas tant de temps que ça !
En conclusion, il reste donc encore beaucoup de travail pour les développeurs, les ESN, et les architectes d’entreprise
Les développeurs doivent devenir des développeurs full-stack
« Les développeurs vont devoir réaffirmer leurs compétences sur l’analyse business, comprendre le métier du client, en quoi les besoins de ce client sont vraiment spécifiques », explique Hervé.
Ils doivent aussi, selon lui, développer leur connaissance des outils open source qui vont pouvoir être connectés autour de ce cœur spécifique pour arriver à bénéficier du meilleur des deux mondes : réutiliser le générique, et développer le spécifique, en aidant le client à rendre explicite son organisation.
Un développeur qui ne connaît pas le métier de son client fera forcément du mauvais code
Les compétences de ce développeur du futur iront « au-delà de la connaissance de la syntaxe d’un langage informatique. Les développeurs doivent avoir davantage d’implication dans la partie conseil », insiste Hervé Rincent.
Ils doivent apprendre à embrasser davantage le cycle de vie de leur développement, en comprenant le besoin et l’architecture.
L’avenir est donc aux développeurs full-stack
« Le full-stack est capable de partir de l’analyse business pour définir une bonne architecture qui va pourra évoluer facilement, puis de coder, et ensuite d’itérer sur ces trois choses de façon rapide », explique Hervé.
Une fonctionnalité est développée et livrée en dix jours permet un feed-back rapide. « C’est cela l’avenir du métier de développeur », conclut Hervé.
————————————————————
Yann Gourvennec a créé visionarymarketing.com en 1996. Il est conférencier et auteur de 6 livres. En 2014, il est passé d'intrapreneur à entrepreneur en créant son agence de marketing numériqueDéfinition marketing digital, un terme utilisé en permanence et pourtant bien mal compris car mal défini.
- Accessibilité des sites Web - 11/10/2024
- 9 conseils pour mettre en œuvre le changement - 10/10/2024
- Le mécénat d’entreprise réinventé par une start-up innovante - 09/10/2024
Voilà un article intéressant mais qui contient certaines affirmations qui méritent, selon moi, d’être nuancées. En particulier en ce qui concerne cette apologie du spécifique.
Certes, quand on est à la tête d’une SSII (on dit ESN désormais voyons !), on aura toujours tendance à favoriser ce réflexe !
« on va pouvoir fabriquer un logiciel qui embarque vraiment sa spécificité et son cœur de métier »… Nous y voilà : combien d’organisations on vraiment une spécificité telle qu’il soit absolument indispensable et inévitable de passer par des développements sur-mesure ?
Car, en dehors de ces vertus supposées, le développement spécifique est non-seulement coûteux mais aussi risqué !
Est-il nécessaire de rappeler le taux d’échec des projets spécifiques ?
Il ne s’agit pas ici de dénigrer gratuitement les propos d’Hervé Rincent qui met l’accent sur certaines dérives (et c’est légitime). Je suis d’ailleurs complètement d’accord avec lui que le recours aux ERP est souvent « un canon pour tuer une mouche ». Pareil pour ce qui est de SalesForce qui ne peut pas être « tout pour tout le monde ».
Mais, entre ces extrêmes, je crois tout de même que le spécifique pur et dur doit être réservé à des cas d’exceptions.
Merci pour ton commentaire Alain, toujours pertinent et intéressant. Et mes excuses pour le délai, indépendant de ma volonté. Je suis d’accord avec toi sur cette histoire des logiciels propriétaires, c’était là mon métier il y a bien longtemps, et je l’ai abandonné dans les années 90, car je sentais que c’était déjà la fin des haricots. C’est à ce moment-là que j’ai quitté le domaine de la maîtrise ouvrage interne pour revenir au marketing. Mais là où Hervé a raison, c’est qu’avec les nouvelles vagues technologiques, et quoiqu’on en pense et je sais ce que tu en penses, j’ai observé au dernier Ready For IT une nette reprise du bon vieux logiciel propriétaire. En fait, les enjeux pour les entreprises et les DSI aujourd’hui sont d’intégrer que ce soit les LLM ou d’autres outils plus solides de machine Learning ou de Deep Learning sur leurs bases internes et en toute sécurité. De fait, cela les oblige à revenir à des solutions qui étaient, semble-t-il, en perte de vitesse, à savoir des développements propriétaires. Et qui plus est, avec la prolifération des clouds de ces dernières années, sobrement nommée multicloud, les coûts ont explosé littéralement sans parler des contraintes environnementales (surtout au niveau des data Centers on le voit en Hollande avec les interdictions de constructions de nouveaux centres de données). Et ainsi on en revient également à des hébergements on premises. Bien entendu cette solution n’est pas meilleure que la précédente qui n’était pas meilleure que celle qu’il y avait avant non plus. Il y a toujours un équilibre à trouver, et c’est bien difficile. Les modes nous font souvent oublier la raison. Ceci étant, j’ai trouvé en discutant avec les DSI de Ready For IT de bonnes raisons de penser que nous revenions à des logiques plus saines, et que nous nous éloignions des dogmes. Qu’il s’agisse de faire du tout propriétaire ou du tout cloud, tout sur étagère, la solution est sans doute quelque part entre les deux.