Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

Nous nous sommes intéressés aux problématiques passionnantes que rencontrent les métiers de la DSI au quotidien et savoir quelles sont celles qu'il faut adresser en priorité.

Présentation du questionnaire, du jeu de données et lien vers le contenu brut disponibles en fin d’article.

Quels sont les trois problèmes les plus importants ?

Dans le cadre de notre étude, nous avons demandé aux répondants de nous dire quels sont les trois problèmes qu'ils jugent les plus importants parmi les suivants :

1. Garder la connaissance du fonctionnement du SI
2. Identifier où positionner une nouvelle fonctionnalité
3. Concevoir une nouvelle fonctionnalité et étudier ses impacts
4. Réaliser, dans un temps raisonnable, une nouvelle fonctionnalité
5. Identifier et qualifier les anomalies de fonctionnement
6. Corriger les anomalies
7. Empêcher les régressions en cas d’ajout de fonctionnalités
8. Mettre à jour technologiquement le SI

Les deux jugés les plus importants sont la difficulté à garder la connaissance du SI et la difficulté à le mettre à jour technologiquement (60% chacun). En troisième vient la difficulté à réaliser, dans un temps raisonnable, une nouvelle fonctionnalité (40%). C’est énorme ! Rappelons-nous qu’il s’agit d’une mission à laquelle les équipes informatiques dédient une part significative de leur temps.

En dernier viennent les difficultés à identifier où positionner une fonctionnalité et à corriger les anomalies, choisies par moins de 7% des répondants.

Penchons-nous désormais plus en détail sur chacun des trois problèmes les plus importants.

1. Difficulté à garder la connaissance du SI

Nous voilà donc sur la première difficulté à surmonter par les métiers qui, s’accordent tous aux mêmes types de blocages :

Le premier, remonté par 78% des répondants, est la présence de documentations qui ne sont pas à jour ou incomplètes. Surprenant puisque quand bien même l'information serait répandue le problème persiste. Alors, la documentation est-elle vraiment “à faire plus tard” ? Les bénéfices d’une documentation de qualité sont-ils mécompris, ou minimisés ? Les développeurs sont-ils laxistes sur ce point ? Les organisations y accordent-elles un budget très/trop limité ? En réponse à cela, nous pourrions par exemple utiliser un proxy qui génère automatiquement la documentation d'une API, centraliser davantage les documents d’architecture, instaurer des documents types pour guider les développeurs, ou instaurer une récompense pour les "documenteurs/euses" assidu(e)s, comme un super-chèque ? Non, tous comptes faits, oublions le dernier.

Le second blocage le plus gênant est le nombre d'interlocuteurs élevé (65%) suivi de la connaissance détenue par un intervenant extérieur (40%) ou diffuse dans l'organisation et peu accessible (37%). Ces problèmes confirment l’importance de ré-internaliser et rendre accessibles les connaissances, ainsi qu’autonomiser les équipes afin de reprendre la maîtrise du SI.

2. Difficulté à mettre à jour le SI technologiquement

La difficulté à mettre à jour le SI technologiquement est le deuxième point jugé le plus important par les répondants. Quels sont leurs freins ?

A 57%, les répondants se disent freinés par le couplage entre les systèmes. Le couplage, c’est le niveau de dépendance d’un client à un serveur, dans une version spécifique. On appelle “le client” le système qui a besoin de l’autre système, “le serveur” pour fonctionner. Le serveur est lui indépendant, il n’a pas besoin du client pour fonctionner. Plus le couplage est élevé, plus il y a de code à modifier quand le serveur change de version et plus il est difficile de le remplacer par un autre. C’est cette problématique que les APIs Semantic REST nous aident à résoudre. Elles permettent, entre autres, aux serveurs de se mettre à jour sans avoir à modifier les clients.

Juste après le couplage, c'est la peur de rompre une fonctionnalité, à cause d'une trop faible couverture de tests, qui est remontée par 50% des répondants. Ce n'est pas faute qu'on nous l'ait dit et redit durant nos études ... ah, les tests ! Parfois vu comme pénibles et chronophages à écrire, ils sont finalement une source importante de sérénité. Dans ce cas, le Test-Driven Development est notre ami. Cette méthode incite les développeurs à commencer par l’écriture des tests.

Finalement, la longueur du processus de déploiement apparaît comme le dernier frein principal. Alors que nous sommes convaincu qu'il est essentiel de faire de la mise en production un non-événement et qu'il existe d'excellents élèves comme Amazon et Netflix, certaines entreprises gardent des processus de déploiement qui peuvent prendre jusqu'à 6 mois. Ce point nous semble particulièrement important à adresser tant la capacité d'une entreprise à mettre sur le marché de nouveaux services et de nouvelles offres est un facteur clé de développement dans la nouvelle économie.

Différentes visions parmi les métiers

Sur cette question, il est amusant de noter la différence d'expérience entre les architectes et les développeurs. Les architectes sont ceux qui dénoncent le moins le couplage, seulement 33% quand la moyenne est de 60%. Quant à la peur de casser des fonctionnalités, les architectes la place dans leur top 3 à 65% tandis que les développeurs le font à 37%. Cela peut s’expliquer par le fait que les architectes sont ceux qui conçoivent les interfaces qui créent le couplage et les développeurs sont ceux qui développent les fonctionnalités et écrivent les tests. Naturellement, nous avons tendance à penser que les problèmes les plus importants sont liés à des missions que nous ne réalisons pas nous même, sinon nous y aurions apporté une solution, non ?

3. Difficulté à réaliser, dans un temps raisonnable, une nouvelle fonctionnalité

Nous avons demandé aux sondés de noter entre 0 et 5 dans quelle mesure ont-ils les moyens de réaliser de nouvelles fonctionnalités dans un temps raisonnable. Nous gardons volontairement l'ambiguïté du sens de “temps raisonnable” pour que chaque répondant puisse l’adapter à son contexte. Il est en effet impossible de déterminer un temps raisonnable applicable à tous les projets et toutes les entreprises. La moitié des répondants vote 3/5 et le score moyen se situe à 2.5. Nous trouvons ce score très faible étant donné qu'il s'agit du quotidien de nombreuses équipes d'informaticiens.

En moyenne, les répondants auxquels des technologies sont imposées les jugent comme étant un facteur de ralentissement à 3/5. Trois sujets peuvent par exemple être adressés pour progresser à ce sujet :

• (i) donner à la DSI les moyens d'étudier de nouvelles technologies plus rapidement,
• (ii) expérimenter de nouvelles technologies sur des projets isolés et formaliser des retours d'expérience, et
• (iii) proposer un catalogue de formation et des groupes de discussion sur les technologies du catalogue de la DSI.

Quant aux trois facteurs qui les empêchent le plus de réaliser les nouvelles fonctionnalités dans un temps raisonnable, 58% nous disent que les spécifications qui leur sont fournies ne sont pas assez riches, 54% sont ralentis par les changements de direction fréquents et 46% par les méthodologies de travail. De nouveaux, nous nous retrouvons confronté à des facteurs organisationnels et managériaux.

Différentes visions parmi les métiers

Lorsque nous regardons plus en détail les réponses en fonction des métiers, une chose nous saute aux yeux : chaque métier est sensible aux problématiques liées à ses missions et aux moyens qu’on lui donne. Les consultants, appelés à répondre à des questions spécifiques et non suivre les développements au quotidien, remontent deux fois plus les problématiques de gouvernance et de méthodologie. Les architectes placent quant à eux la question des technologies imposées en premier, parce qu’elles contraignent leur mission première. Ils votent pour les spécifications pas assez riches dans de moindre proportions que les développeurs, probablement parce qu’ils en sont acteurs tandis que les développeurs en sont dépendants.

Nous en déduisons ainsi que lorsque l’on touche de près aux missions quotidiennes et aux outils donnés à chacun, les retours divergent davantage. Dans ce domaine, il est indispensable de consulter chaque métier pour avoir une vision objective et globale des points à traiter. L’architecte n’est donc pas la voix ni le représentant des développeurs, il observe simplement la situation avec un œil différent.

Conclusion

Parmi les 10 plus importants freins remontés, 6 sont d'ordre organisationnel, 3 d'ordre méthodologiques (documentations, spécifications et tests) et 1 d'ordre technique : le couplage entre les systèmes.

Cela nous confirme l’importance d’adresser le sujet des APIs Semantic REST car elles offrent une solution au principal problème technique du SI. Et alors que de nombreux auteurs écrivent sur les problématiques organisationnelles, rares sont ceux qui étudient en profondeur celles techniques. Pourtant, le couplage technique est un sujet important ! Il augmente significativement le time to market, véritable enjeux stratégique à l'ère digitale. C’est pourquoi nous dédions cette série d’articles à ce sujet passionnant. Nous découvrirons ensemble comment les APIs Semantic REST, un mix d’API Hypermedia et Linked Data, peuvent nous aider. Préparez-vous à découvrir ce sujet ou réviser vos connaissances. Nous vous partagerons quelques pistes pour vous lancer.

Si les questions organisationnelles vous intéressent, de nombreuses publications les abordent sur le web, dans les médias, et sur ce blog. Sachez que nous avons notamment dédié une précédente série aux nouvelles organisations, vous pouvez la retrouver ici.

Rendez-vous au prochain épisode.

Précisions sur le jeu de données

Le questionnaire a été diffusé entre le 4 Décembre 2018 et le 20 Janvier 2019. Les résultats bruts ainsi que la feuille d'analyse sont disponibles sur GitHub. Parmi les 52 répondants, 10 sont architectes, 9 développeurs, 18 architectes et développeurs et 12 sont consultants. Les analyses ont été faites, catégorie par catégorie, en s’appuyant sur les données suivantes :

1. Réponses de l’ensemble des répondants à la question étudiée;
2. Réponses normalisées selon le métier, c.à.d que nous avons pondéré les résultats pour que chaque métier aie le même poids, comme si nous avions obtenu autant de réponses de développeurs que de consultants et autres;
3. Réponses métier par métier.

Dans la suite de cet article, les pourcentages présentés sont ceux normalisés.

Les répondants travaillent dans les 34 entreprises différentes, françaises et internationales, ⅔ sont les entreprises de plus de 1000 salariés.

Nous souhaitions aussi étudier les résultats selon la taille du SI des répondants. Pour cela, nous leur avons demandé le nombre de machines virtuelles qui composent leur SI. Malheureusement, la répartition des répondants est sensiblement déséquilibrée et 10/52 n'ont pas pu répondre. Nous avons ainsi écarté cette piste.