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 ?
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.
Dans le cadre d’analyse ci-dessus nous positionnons les compétences selon les objectifs du développement IT.
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.
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 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.
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.
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.
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.
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 :
Exploration : Valider le problème & la solution
Expérimentation : Valider l'usage
Décollage : Valider les 100 premiers utilisateurs
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 :
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.
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”.
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.
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
En zone innovation technologique
En zone innovation métier
En synthèse, voici les prédominances de compétences/profils selon les objectifs et les “kiffs” de chacun.
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 ;-)