Introduction

La transformation digitale touche tous les secteurs d’activité et surtout tous les types d’entreprises. Grandes ou petites, peu y échappent, et par voie de conséquence la demande autour des développements informatiques est énorme. A tel point que les profils IT courus, deviennent rares et donc chers. Dans ces conditions, innover dans le digital devient compliqué. Et comme innover c’est avancer dans l’inconnu, un projet d’innovation mal articulé peut coûter cher sans que sa pérennité soit pour autant assurée. Lors des comités de direction, les expérimentations digitales deviennent très vite un sujet de crispation.

Que faire alors pour innover, dans un univers aux compétences IT (RH) rares ?

Transformation digitale, peu de secteurs y échappent (src : www.theleanapps.com)

Innovation & développement logiciel – où déployer les compétences

Un premier élément de réponse, et c’est l’un des objets de cet article, est de savoir positionner (puis de suivre) l’enjeu du développement informatique/digital au regard des types de compétences que l’on a à sa disposition. En clair, adapter ses ressources (RH) disponibles à l’objectif du moment à atteindre.

Innovation & développement logiciel – Compétences / Objectifs

Dans le cadre d’analyse ci-dessus nous positionnons les compétences selon les objectifs du développement IT.

Sur l’axe des ordonnées, on positionne les objectifs : en bas la zone rationalisation, destinée aux développements logiciels stables et globalement maîtrisés, en haut la zone innovation, exploratoire et globalement en évolution.
Sur l’axe des abscisses, on positionne les types de compétences, plutôt généralistes à gauche et spécialistes à droite.

Quelle zone pour quel type de développement IT

La zone rationalisation pour le développement des produits ou services au contour globalement maîtrisé

Si l’on est sur un développement informatique au périmètre à peu près clair (zone rationalisation), les besoins que l’on souhaite couvrir par les développements logiciel sont globalement clairs et portés par une vision produit.

Quel focus pour quelles compétences et quels objectifs

Dans le chapitre qui suit, “Cycles de développement de l’innovation”, nous verrons qu’une innovation si elle rencontre le succès passe nécessairement dans une phase de passage à l’échelle avant d’être potentiellement déployée auprès de milliers voire de millions d’utilisateurs (i.e. dans une V1 – version publique).

C’est à ce moment que l’on aboutit à des développements informatiques majeurs pour lesquels Octo est régulièrement appelé. On y déploie alors des équipes produits complètes, pluridisciplinaires et autonomes – 2 à 10 personnes. Si lors de ces phases des éléments d’innovation supplémentaires émergent, alors c’est l’équipe elle-même en charge du développement qui produira dans une zone inconnue/floue relativement étroite les innovations liées aux produits ou services qu’elle a en charge.

Si en particulier, l’équipe a pour objectif le passage à l’échelle d’un logiciel alors des profils architectes, “Ops” ou “Craft” y seront les bienvenus. Ils aideront à poser les fondations d’un logiciel à même de tenir la charge et déployable plus tard à grande échelle dans une V1 publique par exemple.

En zone rationalisation on déploie des équipes produits, pluridisciplinaires, complètes et autonomes

En synthèse, dans la zone rationalisation les investissements sont élevés. L’équipe de développement doit pour l’essentiel se focaliser sur un produit/service relativement mature. Son objectif est de construire un logiciel robuste. L’équipe est pluridisciplinaire et autonome – 2 à 10 personnes.

La zone innovation pour la construction exploratoire des produits et services aux contours encore flous

Si au contraire la vision du produit ou service à développer n’est pas claire, incertaine, que l’on tâtonne pour la définir, que l’on expérimente et teste ses idées via des POC ou bien des MVP jetables alors c’est qu’on est en plein en zone d’innovation. Auquel cas les compétences et profils nécessaires pour travailler dans cette zone ne sont pas les mêmes.

Quel focus pour quelles compétences et quels objectifs

Focus innovation métier : Si l’on cherche davantage à valider une innovation métier, on cherchera plutôt à utiliser des technologies disponibles sur étagères (ou avec un coût d’intégration modeste) pour tester le produit/service métier dans un MVP jetable. L’objectif est bien alors de dé-risquer l’usage (auprès d’une population réduite d’utilisateurs) et non la technique qui le sert. Dans ce cas et pour optimiser les ressources, il sera plus efficace de s’appuyer sur des profils moins techniques mais suffisamment “débrouillards” pour assembler des outils et progiciels (SaaS par exemple) permettant de rendre le service attendu et construire une solution jetable (“MVP ou MVP ?”) Si et seulement si la traction est au rendez-vous alors on pourra envisager une refonte via un développement logiciel dans les règles de l’art. Et nous revoilà dans la zone de rationalisation.
- Notez que dans la zone d’innovation métier (“focus innovation métier”) il est nécessaire d’être en pleine conscience que les solutions produites sont potentiellement imparfaites techniquement, jetables et que la plupart du temps, elles ne passent pas à l’échelle.
Focus innovation technologique : Si l’on cherche à dé-risquer une technologie pour par exemple s’assurer de sa pertinence technique pour un usage métier donné alors on fera plutôt appel de manière ponctuelle à des experts technique/technologique (ex. Blockchain, IA, AR/VR…).

En zone innovation les compétences IT sont à adapter à son objectif

Pour dé-risquer une innovation métier, on s’appuiera sur des profils moins techniques, moins rares mais suffisamment “débrouillards” pour construire une solution jetable par assemblage d’outils et progiciels permettant de rendre effectivement le service métier. Pour dé-risquer une technologie pour un usage métier donné on fera plutôt ponctuellement appel à des experts techniques/technologiques.

Synthèse générale

En résumé selon où l’on se place entre la zone innovation ou rationalisation, les objectifs sont distincts et les profils impliqués complémentaires dans le cycle de l’innovation.

En synthèse : quels profils/compétences pour quel objectif

Cycles de développement de l’innovation

Ces différents moments s’articulent entre eux de manière assez naturelle, nous les avons déjà en partie évoqués. Nous avons schématisé ci-après les passerelles entre chacune des phases possibles de l’innovation.

La chose cruciale dont il faut être conscient est l’enjeu de la phase dans laquelle on entre. Que cherche-t-on à dérisquer : l’usage, la technique, le passage à l’échelle ou 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 permettent de mieux organiser les équipes et d’optimiser les compétences disponibles dans son organisation.

Cycle de développement de l’innovation

Une démarche d’innovation inspirée de la double posture de l’Entrepreneur et du Venture Capitalist a été décrite dans notre précédent article “Innover comme une startup & investir comme un VC (Venture Capitalist)” puis lors de notre matinale sur l’innovation en mai dernier (la vidéo, le CR).

Cette démarche propose de formaliser 4 phases-clés de construction puis de progression des innovations :

Extrait de la démarche innovation : positionnement du POC, MVP, VLab et de la V1

Exploration : Valider le problème & la solution
- Tester sur maquettes et prototypes lors d’ateliers de divergence, convergence par exemple dans une démarche Design Thinking
- Itérer puis valider la meilleure solution en termes de désirabilité utilisateur, faisabilité technique et viabilité économique.

Expérimentation : Valider l’usage
- Tester l’essentiel du service le plus rapidement possible grâce à une solution non pérenne : un POC (“Proof of Concept”) / prototype puis un MVP (Minimum Viable Product)

Décollage : Valider les 100 premiers utilisateurs
- Confronter une VLab 1.0 à ses utilisateurs : une version pérenne développée, distincte du MVP jetable (cf. phase expérimentation), ou de la V1 publique qui vient ensuite. Les pratiques d’”Extreme Programming” et de “Software Craftsmanship” permettent de développer un embryon sain.
Accélération pour dépasser les 1000 utilisateurs et préparer la pérennisation – sur la base de VLab 1.1 et ce juste avant la version publique : la V1.

En synthèse, le rapprochement de notre démarche d’innovation et de notre cadran actuel :

Où suis-je dans mon processus d’innovation ?

Enjeux de la technicité du code

Revenons à la problématique des compétences RH et de leur rareté / coût. Dans la partie innovation, on peut certes avoir besoin d’un expert technique (un spécialiste) sur une compétence étroite. Il sera bien entendu rare et cher mais faire appel à lui ou elle ne se fera que de manière ponctuelle (en une fois ou au fil de l’eau). L’objectif est qu’il soit un accélérateur pour les équipes dont on parlait au départ et qui seront par la suite en charge du développement produit/service dans la zone rationalisation.

Enjeux autour de la technicité du code logiciel

Dans la zone d’innovation métier (en haut à gauche), on s’appuie en particulier sur des outils, technologies ou progiciels dont la technicité de mise en place est moins exigeante en termes de compétences IT. Ils permettent ainsi à des personnes plus transverses et proches des enjeux métiers (moins familières du développement informatique) de mettre en place et à moindre coût des tests d’usages de leurs innovations. Notamment, sur la base de solutions de type SaaS, “No code”, “Low code”, qui une fois assemblées permettent de tester “dans la vraie vie” son innovation produit ou service. C’est une véritable chance pour pouvoir dérisquer des innovations digitales dans un environnement professionnel où les ressources IT deviennent rares et chères.

A titre d’illustration, voici quelques exemples de solutions “Low Code”, “No Code”.

Exemples de solutions “Low Code”, “No Code”

C’est aussi une zone où les experts en UX (“User Experience”) seront cruciaux pour designer le produit ou service innovant. Sur la base d’entretiens, questionnaires, observations terrains, … ils aideront à désigner les innovations en dé-risquant les principales hypothèses et ainsi éviteront de tomber à côté du besoin ‘profond’ des utilisateurs. Ils optimisent ainsi les ressources mises en jeu et évitent les investissements dans une ‘invention’ inutile.

A titre d’exemple, nous pouvons témoigner – pour y avoir participé – que pour tester l’intérêt d’un service de réservation au permis de conduire, le Ministère de l’Intérieur a commencé par un MVP sans code avec une solution SaaS du marché et des opérations manuelles, gérables à petite échelle. L’attractivité de la solution et le succès arrivant, l’équipe s’est alors légitimement posé la question du passage à l’échelle via un développement spécifique (zone rationalisation).

Dans la zone d’innovation métier, l’objectif est de dé-risquer l’usage et non la technique qui le sert. 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. Les compétences nécessaires sont en dehors “hardskills” IT rares et chères.

Conclusion

Selon ce que l’on cherche à dé-risquer : l’usage, la technique, le passage à l’échelle ou 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 phases en phases permettent de mieux organiser les équipes et d’optimiser les compétences disponibles dans son organisation.

En zone rationalisation
- L’objectif est de construire un logiciel robuste.
- L’équipe se focalise sur un produit/service relativement mature.
- Les profils séniors sont cruciaux pour construire un logiciel à large échelle d’utilisateurs et éviter les chausse-trappes. Pour faciliter un passage à l’échelle des profils référents Ops ou Craft peuvent venir compléter le dispositif.

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’appuiera sur des profils moins techniques mais suffisamment “débrouillards”, sorte de “Mario” pour assembler des outils et progiciels (Saas par exemple) permettant de rendre le service attendu et construire une solution potentiellement jetable. On parle ici de compétences en dehors des “hardskills” IT rares et chères. Les experts en UX (“User Experience”) aideront à désigner les innovations en dé-risquant les principales hypothèses et ainsi éviteront de tomber à côté du besoin ‘profond’ des utilisateurs. Ils optimisent ainsi les ressources mises en jeu et évitent les investissements dans une ‘invention’ inutile.

En synthèse, voici les prédominances de compétences/profils selon les objectifs et les “kiffs” de chacun.

Prédominance des profils/compétences IT selon l’objectif et leur “kiff”

Remerciements

Une idée n’émerge jamais d’un seul cerveau. Je voulais remercier ici Arnaud Huon pour nos nombreuses discussions qui ont permis de faire émerger cette analyse et en particulier le tout premier cadran ici présenté. Enfin, merci à Alain Fauré pour nos discussions sur les sujets “Low Code” et “No Code”, sujet qui va être de plus en plus d’actualité ces prochaines années. Si je me trompe que je devienne moine ;-)