Éclairer le futur est notre métier

Taille du texte: +

Culture Innov’ : Osez le code jetable !

Introduction

Dans un projet d’innovation, mieux vaut assumer de jeter son code plutôt que d’investir trop tôt dans la qualité… voici pourquoi. 

Mouvant, changeant, incertain, un contexte innovant est peu prédictif en ce qui concerne son périmètre fonctionnel détaillée. Par conséquent, le coût d’un code logiciel produit dans les règles de l’art devient prohibitif.

Pour autant, en cas de succès de son innovation, le pire des compromis serait de produire un code rapide de mauvaise qualité qui perdure !

Comment faire alors pour tester vite tout en produisant du code efficacement, quitte à le jeter ensuite ? Et sur quel(s) type(s) de code s’appuyer alors ? Et comment faire ensuite pour pérenniser son innovation ?

Rappel de l’épisode précédent : innover puis rationaliser

Dans un précédent article (“Dans un univers aux compétences IT rares et chères comment les optimiser pour innover sans se ruiner”), nous étions arrivés à la conclusion que selon ce que l’on cherche à dé-risquer : “l’usage, la technique, le passage à l’échelle ou encore la version grand public, les critères d’analyse liés à l’IT ainsi que les profils mis en jeu ne sont pas les mêmes. Les passages de phase en phase permettent de mieux organiser les équipes et d’optimiser les compétences disponibles dans son organisation.

 Rappel des différentes zones et focus

Ainsi : en zone innovation technologique 

L’objectif est de dé-risquer une technologie. Les profils juniors très férus de nouveautés et de technologies trouveront relativement bien leur place dans ce type d’environnement.

En zone innovation métier 

L’objectif est de dé-risquer l’usage. On s’appuie sur : des outils, technologies ou progiciels dont la technicité de mise en place est moins exigeante en termes de compétences IT. ex. Solutions No-code, Low-code, scripting, assemblage d’outils. des profils moins techniques mais suffisamment “débrouillards” pour assembler des outils et progiciels (Saas par exemple) et construire une solution potentiellement jetable. En soutien, les experts en UX (“User Experience”) viennent designer les innovations en dé-risquant les principales hypothèses.

Enfin en zone rationalisation 

L’objectif est de construire un logiciel robuste, dont la maintenance (évolutive et corrective) puisse être assurée à coût maitrisé (par exemple grâce à des centres de service).
L’équipe se focalise sur un produit/service relativement mature. Les profils seniors sont cruciaux pour construire un logiciel à large échelle d’utilisateurs et éviter les chausse-trappes.

A quel moment il faut investir dans du code pérenne et à quel moment  cela n’est pas nécessaire

En zone innovation métier : dé-risquer un usage

Lorsque le risque ou l’incertitude d’adoption de son innovation est élevé, il est inutile d’investir dans un code maintenable car la probabilité de le refondre fonctionnellement plusieurs fois est élevée. Souvenez vous que le code traduit concrètement par son implémentation l’intention de votre innovation, il ne peut être vague. Hors au début de l’élaboration de son innovation l’usage est peu stable, incertain, s’épuiser / épuiser ses ressources sur un code de qualité, dans les règles de l’art, vous détourne de votre objectif principal qui est bien plus fondamental à savoir : dérisquer l’usage. 

En résumé, l’arbitrage d’investissement se traduit par le schéma suivant :

En conclusion, le code jetable est au service immédiat d’une validation à moindre coût d’une idée ou d’un concept innovant. 

Mais de quel type de code jetable parle t on ?

On peut s’appuyer sur une équipe de développeurs pour produire du code “quick & dirty”.  C’est bien entendu possible mais il faut être en pleine conscience que le code produit n’est pas pérenne, qu’il a un niveau de qualité “juste suffisant” et que pour le produire à coût raisonnable, c’est à dire en peu d’itérations, l’équipe doit être suffisamment mature donc expérimentée. Si on généralise cette approche sur les projets d’innovation digitale, le risque est de se retrouver rapidement à cours de développeurs confirmés. Cette approche reste donc possible mais de manière ponctuelle.

L’alternative consiste à s’appuyer davantage sur des solutions de type Low-code ou No-code. Avec ce type d’approches on a la possibilité de tester un vrai service en production (le Low-Code comment ça marche?). La mise en place de ce type de briques est rapide et peu coûteuse dans les phases d’amorçage. Elles sont d’autant plus intéressantes qu’en plus de masquer la complexité du code (du code est bel et bien existant en sous jacent), elles masquent la complexité du déploiement et du run dudit code. 

Ce n’est toutefois pas magique, il est recommandé d’en comprendre le périmètre d’actions et les limites. Certes, ces solutions limitent le besoin en expertise pure liée au code mais il est recommandé d’avoir des notions de conception et de programmation afin de correctement orchestrer les briques entre elles ou tout simplement d’en comprendre les limites et les enjeux. De ce fait, on peut avoir un besoin de formation ou d’expertise ponctuelle sur ce type d’outils , histoire de partir du bon pied (voir notre formation No-code).

Les solutions No-code, Low-code permettent bien de diminuer l’incertitude d’adoption de son innovation métier et d’en affiner son contour tout en se confrontant au terrain. Que ladite innovation fonctionne ou non, on valide ou invalide ses hypothèses en dépensant peu. 

En zone innovation technologique : dé-risquer une technologie

Si l’on se place dans la zone d’innovation technologique, on cherche à dé-risquer une technologie pour par exemple s’assurer de sa pertinence technique pour un usage métier donné. On fera plutôt appel de manière ponctuelle à des experts techniques/technologiques (ex. Blockchain, IA, AR/VR…) dont la production logicielle aura aussi une pérennité limitée. L’enjeu est de s’assurer avant tout que la technologie est pertinente dans un contexte métier donné car à ce stade son adoption dans la durée n’est pas encore validée. 

Le MVP est jetable. Corollaire : le code qui le soutient aussi ! Au moment ou l’on décide de partir sur une solution de type MVP métier ou technique, il faut prendre l’hypothèse de base que le code produit est potentiellement jetable.

Ensuite, pour ces deux cas (innovation métier ou technologique), son hypothèse validée alors se reposera la question de la pérennité du code et d’une refonte éventuelle des premières implémentations logicielles.

Pour dérisquer, tester vite, utiliser des solutions logicielles ou du code à façon pour lesquels la pérennité ne doit pas être un enjeu

En zone rationalisation : construire un logiciel robuste

Inversement, lorsque le risque ou l’incertitude liée à l’adoption de son innovation est réduit alors on peut investir dans des développements pérennes et maintenables et qui techniquement passent à l’échelle.

Les ressources et les compétences  sont alors celles plus traditionnellement utilisées dans le développement informatique d’un produit logiciel à façon, par l’intermédiaire de prestation ou par une équipe de développeurs internes (voir notre blog : comment optimiser les compétences IT sans se ruiner)

En synthèse, si l’on scrute l’aspect financier, l’investissement consenti est inversement proportionnel aux risques ou à l’incertitude d’adoption d’un produit ou service innovant.

 

L’investissement consenti est inversement proportionnel aux risques ou à l’incertitude d’adoption d’un produit ou service innovant

Convergence des modèles : enjeux, timing et liens avec les horizons de l’innovation

Dans un précédent article, nous exposions la convergence de modèles pour accompagner et évaluer les maturités d’usage, technologiques ou de marché des innovations.

A partir de perspectives différentes, nous avions constaté que des modèles complémentaires et superposables convergent dans les histoires qu’ils racontent. Cette convergence permet de profiter de leur cohérence pour enrichir l’accompagnement des innovations et en particulier de profiter des recommandations et bonnes pratiques issues de chacun d’entre eux.

En projetant notre cadran actuel sur l’un des modèles qu’est celui des horizons, popularisé par C. Christensen, nous aboutissons à la synthèse ci-après :

Profitez de la cohérence de modèles de diffusion de l’innovation pour tirer partie des bonnes pratiques de chacun d’entre eux

Les profils (Quelle équipe pour quel horizon?) qui seront à l’aise dans chaque horizon ne sont pas nécessairement les mêmes. En particulier, il faudra gérer la susceptibilité des innovateurs en horizon 3 (émergent) qui ont du mal à se séparer de leur bébé en le confiant à un business développeur par exemple dans l’horizon 2 (activité en croissance).

Si les membres d’une équipe de l’horizon précédent sont à l’aise avec les objectifs du nouvel horizon, il n’y a pas d’objection à ce qu’ils poursuivent dans l’horizon suivant. Le point clé étant de s’assurer que les personnes sont parfaitement à l’aise et aptes vis à vis des objectifs du nouvel horizon.

Cette adaptation d’organisation, se traduit dans le code logiciel produit. Dans le cas de l’horizon 3 (émergent) où il faut être à l’aise avec l’inconnu et l’adaptation permanente, cela peut se traduire par la non-pérennisation du code produit (via des solutions de No-code, Low-code ou via des POCs technologiques) et par le fait que l’équipe assume pleinement qu’il puisse être jeté. Dans l’horizon 2 (passage à l’échelle) et 1 (maturité), le code logiciel produit doit pouvoir passer à l’échelle et être maintenable à coût maîtrisé par l’équipe. Les compétences et les ressources mises à disposition de cette maintenance ne sont plus identiques à celles de l’horizon 3 (émergent). 

Conclusion

En résumé considérer les solutions Low-code / No-code, dans une approche Lean Startup, pour construire (non exhaustif) :

Un MVP afin de valider un concept, préciser une proposition de valeur sur une innovation tout en se confrontant au terrain, Des sites web/sites mobiles simples – exposition d’informations – : exemples d’outils – Webflow, Strikingly, Squarespace, Wibli, Wix… Des applications app web/mobile – avec actions transactionnelles – : Bubble, Glide, … Une combinaison d’outils via l’automatisation de process : Zappier,… Un stockage robuste hybride en mode tableur-base de données, mais avec les fonctionnalités d’une base de données (Airtable), …

Attention, il n’y a rien de magique non plus….même si on n’a pas à coder des algorithmes complexes, il faut savoir concevoir une application, designer et orchestrer des tâches dans un processus et enfin connaître les possibilités comme les limites de ce type d’outils. 

 

« Attention/ Warning/ Achtung ! Jetez votre code jetable. La plupart des projets innovants prennent le pire des compromis : coder rapidement du quick and dirty, et construire les évolutions sur des mauvaises fondations qui freineront ses évolutions. Notre recommandation est d’utiliser les outils No-code/ Low-code pour tester rapidement un MVP jetable. Une fois le concept validé sur le marché, il faut investir dans une solution pérenne avec les principes de qualité craft. Si votre code est jetable, il faut le jeter !

Dans tous les cas, il aura rendu le service qu’on attend de lui : vous permettre de tester votre innovation sur le terrain à coût très maîtrisé; et ainsi dérisquer l’usage et valider sa proposition de valeur auprès d’utilisateurs/clients.

Pour aller plus loin avec le No-code et le Low-code

A la DuckConf 2020, le 28 Janvier 2020 une session sera dédiée aux outils Low-Code, No-Code. ”No Code : la démocratisation du développement” (par Alain Fauré et Laurent Sollier).

 

Formation OCTO Academy : “Développer une application sans savoir coder; mise en pratique des outils “No-Code

 

Article sur notre blog Octo : Low-Code comment ça marche? par Alain Faure et Laurent Sollier

 

Nous recommandons l’écoute du podcast d’Alexis de Contournenment.io dans son interview de Charles Thomas sur l’usage du Low/No-code dans la construction de la société Comet.Vous y comprendrez l’approche de non développeurs dans la construction d’une Startup sur la base de tels outils, de leur puissance et de ce qu’ils permettent de tester à peu de frais et surtout comment ils permettent aux startuper de se concentrer sur l’objectif principal qui devrait être celui de tout startuper : dérisquer l’usage et valider sa proposition de valeur auprès d’utilisateurs/clients.

 

Auteur d'origine: Sylvain Fagnent
ReDoS (Regular expression Denial of Service)
Une équipe austro-américaine découvre la plus gran...
 

Commentaires

Pas encore de commentaire
Already Registered? Login Here
Guest
mercredi 19 février 2020

Image Captcha

Copyright © 2020 SLA
167 Chemin des Combes 74110 Essert-Romand - tel : 04.50.83.06.79 - Mobile : 06.75.23.84.11

Mentions légales    -    Politique de confidentialité    -    Plan du site

IMPORTANT

copyright

 Notre blog est un blog de Curation, aussi les articles publiés proviennent-ils de différents flux RSS et nous ne prétendons, en aucune manière, nous en attribuer la paternité. Si vous souhaitez lire l'article original sur le site d'origine, il vous suffit de cliquer sur "Lien d'origine " qu se trouve à la fin de l'article.

Traduire

frendeitptrues

Rechercher

Témoignages

Ils ont assisté à nos séminaires et ils donnent leurs avis.

Ce que les participants en pensent

Programme 2020

Fiche pédagogique

Aller au haut