« Présomptueux ? Non, je suis convaincu que l’APM sert en premier lieu les développeurs. Il semble juste qu’il existe un manque d’évangélisation sur ce à quoi l’APM peut être utile auprès de la communauté », avance Thomas Arnaud, directeur technique de Nudge. Il développe ici…
Si je devais utiliser une métaphore, je dirais que l’APM est à une application ce que la « boite noire » est à un avion. Si on l’envisage de la sorte, pourquoi donc se priver encore d’APM ?
Les technologies de gestion de la performance des applications sont bel et bien les alliées des équipes de développement.
Tout d’abord, parce qu’elles leur font gagner un temps précieux au niveau de la détection des bugs. Fini le temps où les équipes passaient des heures, des jours, voire des semaines à déterminer s’il s’agit d’un problème applicatif, système ou réseau parfois sans vraiment avoir d’autres solutions que de le contourner – et sans finalement le résoudre.
Deuxième raison : parce que l’APM permet aux développeurs de se focaliser sur l’essentiel pour eux : développer (conception, écriture du code, tests …). De nombreuses équipes de développement passent moins de la moitié de leur temps au développement, étant le reste du temps bien souvent accaparées par la maintenance. En s’appuyant sur un outil d’APM, elles économisent du temps sur la recherche et la résolution des bugs ; elles peuvent ainsi se repositionner pleinement comme concepteur et créateurs d’applications et non comme correcteurs de dysfonctionnements logiciels !
Troisième point : avec l’APM, les développeurs peuvent comprendre les incidents directement en production. Le meilleur moyen de s’assurer de l’efficacité d’un correctif, c’est de connaître le contexte dans lequel l’anomalie se produit. Cette étape d’identification du contexte peut parfois relever de la gageure. Ici, l’APM va apporter des informations précises sur le contexte de l’incident (paramètres de requêtes, code d’exception, parcours de l’utilisateur …) qui feront gagner un temps précieux au développeurs pour diagnostiquer et résoudre au plus vite l’incident.
Quatrièmement : la nouvelle génération de solutions d’APM orientée DevOps permet de faire le lien entre les équipes informatiques. L’application qui tourne en production est souvent vue par les équipes de production comme une boite noire. L’APM apporte de la transparence et permet aux différents interlocuteurs de disposer d’informations et d’indicateurs compréhensibles et accessibles par chacun. Cela vaut aussi dans des contextes où les interlocuteurs appartiennent à des entités différentes (hébergeur, infogérant, support, TMA …) ou bien lorsque l’application a un passif fort, souvent non documenté et dont une bonne partie de la connaissance du fonctionnement s’est perdue avec le temps.
Enfin, l’APM couvre quatre principales exigences, une fois l’application mise à disposition des utilisateurs :
-éviter de jouer au ping pong entre le développement et la production en cas de ralentissement observé de l’application
-améliorer en continu la performance des applications
-réduire drastiquement le temps écoulé entre l’apparition d’un incident et sa résolution, voire l’anticiper
– et comprendre les sources d’insatisfaction mais aussi de satisfaction des utilisateurs métier.
Sans compter qu’avec les nouveaux modèles de business, cette technologie n’est plus uniquement réservée à la supervision des grosses applications métier, elle se place au service de toutes les applications de l’entreprise et est bien plus accessible qu’on ne l’imagine…
Alors, et si finalement l’APM libérait les équipes de développement d’une bonne partie de ce qui les ralentit pour leur permettre de faire ce qui constitue le cœur de leur métier et être plus épanouis ?
