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.
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 :
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).
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.
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)
**
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.
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),
- ...
_
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).
Article sur notre blog Octo : Low-Code comment ça marche? par Alain Faure et Laurent Sollier
Nous r 