C'est une distinction subtile mais essentielle de l'ITSM, et la comprendre change la façon de travailler — car confondre les deux enferme un service dans la réparation perpétuelle des mêmes pannes. Un incident, c'est une interruption ou une dégradation d'un service qu'il faut rétablir au plus vite. L'objectif de la gestion des incidents est la rapidité de rétablissement : remettre l'utilisateur ou le service en marche le plus vite possible, quitte à appliquer une solution de contournement temporaire. Quand un poste ne démarre plus, quand une imprimante est en panne, quand un utilisateur ne peut plus se connecter — ce sont des incidents, et on les traite dans l'urgence pour rétablir le service. C'est le quotidien du support (niveau 1). Un problème, c'est la cause sous-jacente d'un ou plusieurs incidents. L'objectif de la gestion des problèmes n'est plus de rétablir vite, mais d'éliminer la cause racine pour que les incidents ne se reproduisent plus. La question n'est plus « comment remettre en marche ? » mais « pourquoi cela casse-t-il, et comment l'empêcher définitivement ? ». Une image éclaire tout : imaginez une fuite d'eau. Éponger l'eau à chaque fois qu'elle apparaît, c'est la gestion d'incident — nécessaire, urgent, mais sans fin si la cause persiste. Réparer le tuyau qui fuit, c'est la gestion de problème — cela demande plus de temps et d'investigation, mais cela règle la question définitivement. Le lien entre les deux est direct et pratique : quand un même incident revient encore et encore (dix utilisateurs signalent le même bug, une imprimante retombe en panne chaque semaine, un logiciel plante régulièrement pour tout un service), c'est le signal qu'il y a un problème derrière ces incidents répétés — une cause de fond qu'aucune réparation ponctuelle ne résoudra. Continuer à traiter chaque occurrence comme un incident isolé, c'est éponger indéfiniment sans jamais réparer le tuyau : épuisant, coûteux, et frustrant pour tout le monde. Pourquoi cette distinction compte-t-elle tant en pratique ? Parce qu'un service IT qui ne gère que des incidents est condamné à réparer sans cesse les mêmes pannes, débordé, sans jamais progresser. Un service qui gère aussi les problèmes réduit structurellement le flux d'incidents en éliminant leurs causes — c'est ce qui permet de sortir de la spirale du « pompier permanent ». C'est aussi tout l'intérêt de tracer les tickets (niveau 1) : sans traçabilité, on ne voit pas qu'un incident se répète et on ne détecte jamais le problème sous-jacent ; avec des données, les tendances sautent aux yeux (« ce type d'incident représente 30 % des tickets ce mois-ci — il y a un problème à traiter »). La maturité d'un service IT se mesure en partie à sa capacité à ne pas se contenter d'éteindre les incendies (gérer les incidents), mais à investiguer et éliminer leurs causes (gérer les problèmes) — pour qu'il y ait, au fil du temps, de moins en moins d'incendies à éteindre. C'est un changement de posture : passer de « réagir » à « améliorer ».

Pour débuter tout petit, un tableur peut dépanner ; mais dès que le parc grandit un peu, un vrai outil devient rapidement rentable — et s'obstiner sur le tableur finit par coûter plus cher en temps et en erreurs que l'outil qu'on cherchait à éviter. Reconnaissons d'abord la légitimité du tableur : pour une poignée de machines, un fichier listant les postes, leurs caractéristiques et leurs licences est mieux que rien, gratuit et immédiat. C'est un point de départ acceptable pour une très petite structure. Mais ses limites apparaissent vite, et elles sont sérieuses. Le tableur est manuel : il faut le tenir à jour à la main, ce qui, dans la réalité d'un service occupé, signifie qu'il dérive inévitablement — on oublie de noter un nouveau poste, un changement, un départ, et au bout de quelques mois l'inventaire ne reflète plus la réalité, donc ne sert plus à rien (un inventaire faux est presque pire qu'une absence d'inventaire, car il donne une fausse confiance). Il ne fait que l'inventaire : il ne gère pas les tickets, ne relie pas les incidents aux machines, n'offre pas de base de connaissances, ne suit pas l'usage réel des licences. Il ne découvre rien automatiquement : chaque information doit être saisie. Il passe mal à plusieurs mains (conflits, versions). Un vrai outil de gestion de parc / ITSM (comme GLPI, qui a l'avantage d'être open source et gratuit) apporte des capacités qu'un tableur ne peut pas offrir. L'inventaire automatique : l'outil détecte et recense les machines et leurs caractéristiques par le réseau, et se met à jour tout seul — fini la dérive de l'inventaire manuel. L'intégration : le parc, les tickets, les licences, la base de connaissances sont reliés dans un même système (on voit l'historique des incidents d'une machine, on associe une demande à un actif). La gestion des tickets et des processus (incidents, demandes) structurée. Le suivi des licences croisé avec l'inventaire réel (pour éviter le gaspillage et l'illégalité — niveaux 1 et 4). La traçabilité et le travail à plusieurs. En résumé, le tableur inventorie (mal, à la longue) ; l'outil gère le parc et le service, de façon fiable et intégrée. Le seuil de bascule est atteint bien plus tôt qu'on ne le croit : dès quelques dizaines de machines et quelques utilisateurs, le temps perdu à maintenir un tableur imparfait et les problèmes causés par un inventaire faux dépassent l'effort de mise en place d'un outil — surtout quand des solutions gratuites et éprouvées existent. Le vrai coût d'un outil de gestion de parc n'est d'ailleurs généralement pas la licence (souvent gratuite ou modérée) mais le temps de mise en place et d'appropriation ; c'est un investissement initial qui se rentabilise vite en efficacité, en fiabilité et en capacité d'amélioration. La recommandation : le tableur comme dépannage transitoire pour un parc minuscule, mais dès que l'on gère un vrai parc, un outil dédié n'est pas un luxe mais un fondement d'une gestion maîtrisée.