Les bugs informatiques, comme tous défauts, sont coûteux lorsqu’ils sont traités tout comme lorsqu’ils ne le sont pas ! Alors, que faire ? Comment faire ? Affronter, contourner ou fuir ? Quels seraient les outils et les stratégies possibles des entreprises face à ces fréquents défauts informatiques ?
De quel bug (ou bogue) parle-t-on vraiment ?
Le défaut informatique, communément appelé bug (anglophone) ou bogue (francophone), revêt des dimensions de natures organisationnelles et technologiques difficilement conciliables. La conséquence d’un bug est connue. Ce défaut sera à l’origine d’un dysfonctionnement plus ou moins grave. Mais sa définition l’est moins.
Deux approches s’opposent pour définir un bug au sein d’un programme informatique ou plus largement d’un système d’information (SI). La première est technique et documentée. Elle apparaît comme un écart avec une référence ou un référentiel. Le bug est dans ce cas une non-conformité ! La seconde est cognitive et liée à la perception. Elle reflète un écart avec une interaction souhaitée ou envisagée par l’utilisateur final. Le bug est dans ce cas une déception ! Dans les deux cas, les conséquences sont le plus souvent financières, opérationnelles et/ou médiatiques.
Défaut, anomalie, omission, incompétence, malveillance… ?
Restons donc dans le domaine de l’informatique où le bug est un défaut de conception d’un programme informatique à l’origine d’un dysfonctionnement quelconque qui empêche le programme de fonctionner correctement et d’atteindre son but. Ce défaut dans le programme peut résulter d’une anomalie, d’une omission, d’une inattention, d’une incompétence, d’une erreur voire – pourquoi pas ! – d’une malveillance. Même si le terme de « debugger » peut paraître impropre (corriger ou réparer sont souvent préferables) c’est donc bien l’acte de remettre en état le programme pour lui permettre de fonctionner.
Avant de traiter le bug, il nous faut donc caractériser ce très ancien compagnon d’infortune de tout informaticien. Ce défaut – cet écart – informatique peut donc être volontaire ou involontaire. S’il est volontaire, il peut être d’origine interne ou externe, nous parlerons alors de malveillance, d’incompétence, de manipulation, d’escroquerie, d’intrusion, d’insuffisance des ressources (virus, vers, configuration…). S’il ne l’est pas, il peut également être d’origine interne ou externe, nous parlerons d’anomalie, d’erreur, d’incapacité, de coûts de sur/sous-qualité, d’intempérie, de non-conformité matérielle (panne, plantage, paramétrage inadéquat…).
Les caractéristiques sont nombreuses et les origines multiples. En général, l’origine de la plupart des bugs oscille entre incompétence, incapacité et suffisance.
Comment les traiter ?
Comme tout dysfonctionnement, les bugs informatiques génèrent des coûts directs, indirects, cachés et d’opportunités. La question de l’évaluation de la disponibilité d’un système est classique dans le cas du traitement des bugs. Il s’agit de la probabilité que le système puisse fournir le bon service, au bon endroit, au bon utilisateur et au bon moment (plus elle est proche de 100 %, plus le système est fiable).
Ainsi, face à la probabilité de réels désastres économiques et organisationnels, de nombreux outils de gestion du cycle de vie des logiciels, et donc de leurs bugs, existent. Toutefois, la diversité des dimensions et natures des bugs a notamment pour conséquence de mettre en tension l’utilisation de ces outils et leur mesure de la qualité. Plusieurs questions se posent aux concepteurs, utilisateurs et autres administrateurs de SI.
Comment identifier, suivre, classer les bugs ? Quel angle d’attaque retenir entre l’écart à une référence documentée et/ou l’écart à un besoin d’usage ? Le bug qu’il est urgent de corriger pour une partie prenante (par exemple un client), présente-t-il le même caractère d’urgence pour une autre partie prenante (par exemple un fournisseur) ? Qui va décider ? Qui va payer ? Qui va participer à cet angoissant « tracking » ?
Tentons l’impossible…
Le retour au terrain, aux outils et au marché – qui a profondément été transformé par les solutions cloud computing – est indispensable pour aborder ces questions. Nous pouvons ici détailler une expérience qui s’appuie sur la création d’un site expérimental temporaire. Nous avons pu lister, identifier et caractériser environ 200 solutions logicielles de gestion de situations (issue tracking tools). Nous nous sommes particulièrement intéressés aux fameux logiciels de bug tracking tools et à leur impact.
Il ressort premièrement de cette recherche en cours de communication un réel partage, au sein de ces outils SI, d’une fonctionnalité majeure comme l’identification numérotée de la situation à traiter. Il en ressort également la présence quasi systématique d’une évolution possible du classement du statut ou de la maturité des situations et des bugs au fur et à mesure de leur cycle de vie. Il apparaît enfin que, sur l’ensemble des outils informatiques observés, dans plus de 90 % des cas, existe une fonctionnalité sensible qui permet la priorisation des situations et donc la hiérarchisation des bugs à traiter.
La question du traitement du bug est donc renvoyée à celle de la détermination et de la hiérarchisation de son degré d’importance perçue a priori. Ainsi il y aura intervention et éventuellement réparation en fonction de la perception des coûts induits. Notamment : qui sera impacté ? quels dégâts ? quels coûts ? dans combien de temps ? quel plan B ?… plutôt que de leur réalité informatique, organisationnelle et/ou économique.
… Mais restons pragmatiques !
Cette prévalence de l’identification et surtout du classement de situations et bugs en fonction de critères de priorités est compliquée à aborder dans l’organisation. Dans le meilleur des cas, cette hiérarchisation se calera sur les classements qui renvoient à la gravité des effets d’une éventuelle défaillance modélisée par la méthode AMDEC (MIL-STD-1629A). Certes cette méthode d’analyse et classements des risques par leur criticité est parfois controversée mais elle reste largement diffusée et déployée. Quelle que soit la méthode d’analyse, de nombreuses questions complexes, en termes de processus décisionnel, se posent alors aux décideurs. Quel contenu et quel format serions-nous prêts à ajouter à la description des bugs informatiques pour agir sur leur classement habituel ? Peut-on intégrer des éléments qualitatifs (perception, bien-être, qualité…) ? Doit-on supprimer certains critères complexes à traiter (langage, tests…) ?
Finalement faut-il traiter ou ne pas traiter les bugs ?
Comme toujours, la question du traitement (faire ou ne pas faire ?) se pose face à un dysfonctionnement. La question suivante est celle du « pourquoi faire » ? Puis évidement arrive celle du « comment faire » ? À ce stade seulement, peuvent alors intervenir certains outils de débogage voire – quand le mal est fait ! – certaines entreprises dont le métier est de réparer les dégâts numériques
Si nous nous référons au coût a priori du traitement, il peut être (clairement) intéressant de ne pas intervenir et d’attendre les (éventuels) dégâts pour les affronter et peut-être les réparer. Cet attentisme de facto dépasse le champ de l’informatique, il peut d’ailleurs être opportunément valorisé au travers d’un travail en commun de la part de communautés open sources. L’accès ou non au code source est un critère majeur pour analyser le cycle de vie des bugs…
Néanmoins, en termes managériaux, ces non-décisions sont en cohérence avec la complexité croissante et les coûts élevés de déploiement de stratégies de contrôle ex ante. Ceci a pour conséquence la montée en puissance de stratégies de contrôle essentiellement ex post et donc l’acceptation d’un certain volume de bugs. Des dysfonctionnements qui seront donc traités si et seulement le marché les expose à la lumière !