Discussion :

[souviron34]

Qu'en dites-vous de cela ?

J'en dis que c'est très intéressant... mais très spécialisé...

Des sysadmin, "monitoring security", "recording low memory", "detecting attacks"...

Ce n'est pas du domaine global d'une application "normale"...

Et qu'on parle alors d'un type (très) particulier de logging...

Bref, ça me semble certainement de bons outils et un bon principe pour le(s) but(s) mentionné(s)..

Mais que le but du PO et le thread qui s'en suit ne semble par rentrer du tout dans ce cadre..

(à vrai dire, je ne sais pas si le PO faisait une appli de sécurité, mais j'ai comme un doute d'après ses questions... et d'après ce qu'il en dit Mandraxxx non plus)

[Mandraxx]

Bonjour,

eh ben voui, et c'est là que réside le point que je fait : dans une approche "normale", c'est justement l'architecte/CP qui a le plus de bouteille qui est censé établir l'architecture globale..

C'est ce que je voulais dire et que tu explicites : maintenant on "éclate" les rôles et on donne des "diplômes " de CP ou d'"architecte" qui fait qu'on prend dans des fonctions demandant de l'expérience des gens qui n'ont pas de "bouteille", du coup on est obligé d'inventer un nouveau poste

"L'urbaniste" n'est donc en rien une profession à part entière, à mon sens, c'est le reste qui n'est pas adapté..

100% d'accord avec toi.

Maintenant, par rapport au problème du thread, que "l'incompétence" (entre guillemets) soit du domaine de la mauvaise conception ou d'un mauvaix choix de personnes / organisationnel, il n'en reste pas moins que je ne la qualifierais pas de "choix technique"..

Et que donc, je maintiens ma position que utiliser un outil "externe" et modifier les sources pour faire du logging est une aberration conceptuelle...

Mais je pense qu'on va s'arrêter là sur ce sujet, non ?[*] Note : et ça touche tous les domaines Maintenant, pour être concierge il va falloir un diplôme : Désormais devenir gardien d'immeuble s'apprend à l'école

Tout à fait, et d'ailleurs, tu as parfaitement répondu à ma question et je te remercie d'avoir pris le temps d'argumenter ta réponse de façon aussi détaillée.
Je comprends maintenant ton point de vue et j'ai trouvé cet échange très enrichissant: cela va certainement influer sur ma façon de concevoir à l'avenir.

Don merci à toi.
@+

[Melem]

J'en dis que c'est très intéressant... mais très spécialisé...

Des sysadmin, "monitoring security", "recording low memory", "detecting attacks"...

Ce n'est pas du domaine global d'une application "normale"...

C'est sûr que ce n'est pas dans les applications de tous les jours que l'on s'en sert, ça se saurait ! Pour ma part par exemple, ce n'est que très récemment que j'ai commencé à m'en servir (au boulot).

Et qu'on parle alors d'un type (très) particulier de logging...

Dans tous les cas, c'est du logging tous court. Il n'y a pas de type particulier de logging. Chacun par contre, en fonction de son métier, utilise les logs à des fins parctulières (détection et prévention de pannes, détection d'attaques, etc.). Au boulot par exemple, on est plus dans l'optique détection et prévention de pannes.

Mais que le but du PO et le thread qui s'en suit ne semble par rentrer du tout dans ce cadre..

(à vrai dire, je ne sais pas si le PO faisait une appli de sécurité [...])

Le but n'est pas de faire de la sécurité (par exemple), mais de générer des informations qui pourraient plus tard aider les experts en sécurité. En gros, pour l'admin sys, la règle est simple : tout le monde devrait utiliser le logging dans leurs applications. En d'autres termes, les développeurs devraient faire plus d'efforts pour que eux en fassent moins . En pratique, et au détriment des admin sys, rares sont ceux qui le font bien sûr, à part ceux qui en ont vraiment besoin .

[souviron34]

j'ai trouvé cet échange très enrichissant...Don merci à toi.

De rien , c'est à ça (entre autres) que doivent servir ces forums : partager des expériences et discuter, et (en tous cas c'est comme ça que le conçois) tenter, pour ceux ayant comme moi déjà une assez longue carrière derrière eux, de parer au "trou" de générations par le passage de l'expérience... Et quelques remarques de bon sens "en dehors" de la technologie pure...

Dans tous les cas, c'est du logging tous court. Il n'y a pas de type particulier de logging.

Euh.. Bien sûr que si : les moteurs de BD ont leur propre système lorsqu'on fait un transaction, et les softs autres ont leur propre besoins..

Le logging de ressources systèmes est un domaine particulier, qui n'est pas du même ordre que le logging des opérations d'un logiciel...

Chacun par contre, en fonction de son métier, utilise les logs à des fins parctulières (détection et prévention de pannes, détection d'attaques, etc.). Au boulot par exemple, on est plus dans l'optique détection et prévention de pannes.

Le but n'est pas de faire de la sécurité (par exemple), mais de générer des informations qui pourraient plus tard aider les experts en sécurité.

euh....

Il me semble que ton argument est spécieux : si je fais une appli d'affichage de cartes, ou un visualseur MPEG, une consome MIDI, un jeu de poker, une appli de e-learning, un logiciel à destinations d'utilisateurs, en quoi ai-je besoin d'aider des experts en sécurité ??????????

En gros, pour l'admin sys, la règle est simple : tout le monde devrait utiliser le logging dans leurs applications. En d'autres termes, les développeurs devraient faire plus d'efforts pour que eux en fassent moins . En pratique, et au détriment des admin sys, rares sont ceux qui le font bien sûr, à part ceux qui en ont vraiment besoin .

Et ils ont bien raison...

Ce sont des buts différents...

Que les sysadmin se développent des outils pour eux, grand bien leur fasse..

Que des développeurs d'applications prennent en compte les besoins des sysadmin, ce n'est pas de leur ressort ni dans leurs préocuppations - et ça ne DOIT pas l'être..

Si je fais un soft pour une machine médicale, la partie "sécurité" est entièrement détachée de la partie fonctionnelle, et correspond à un cahier des charges différent (accès par le SAV, interdiction de modification du clavier, etc etc), établi par le fabriquant pour lui-même, et non pas établi par le client...


Tu es sans doute déformé par le boulot que tu fais, mais dire que le logging des ressources systèmes devrait être pris en compte par les développeurs est..... absurde...

Un soft est fait pour tourner.

Si le marketing ou le SAV ou simplement la technologie fait que les machines changent, un bon soft doit continuer à tourner, qu'on ajoute de la mémoire, qu'on en retire, que ça aille plus vite ou pas, que on double les DD ou pas...

La surveillance de ces paramètres n'est pas du ressoirt du logiciel.. et heureusement, sinon la fabrication d'un soft (déjà fort complexe) serait à s'arracher la tête..

[souviron34]

Le but n'est pas de faire de la sécurité (par exemple), mais de générer des informations qui pourraient plus tard aider les experts en sécurité. En gros, pour l'admin sys, la règle est simple : tout le monde devrait utiliser le logging dans leurs applications. En d'autres termes, les développeurs devraient faire plus d'efforts pour que eux en fassent moins . En pratique, et au détriment des admin sys, rares sont ceux qui le font bien sûr, à part ceux qui en ont vraiment besoin .

Je vais ajouter 2 exemples :

En 1996, je dois concevoir une appli style SIG (sous X11), avec zoom panoramique, qui ira chercher ses données dans des bases de données réparties en grappes..

• Exemple 1 : la partie graphique
  
  X11 a une erreur fatale lorsque l'on demande une fenêtre-cache supérieure à une certaine taille (équivalent d'un malloc)
  
  Dans mon code, j'ai :
  
  
  
  • le fait de "catcher" cette erreur fatale, et alors d'obliger à ne prendre que la taille minimum (la taille de la fenêtre)
    
    
  • Un paramètre - dans un fichier de config, mais modifiable interactivement à l'interface - donnant une taille max en Meg.
  
  
  Résultat : quelle que soit la mémoire de la machine sur laquelle je tourne , je ne crashe jamais (et j'autorise un zoom infini), et suivant l'utilisateur, sa machine, et les directives du SI, la taille max autorisée peut être imposée par le SI
  
  Avec le même soft, sans rien avoir à modifier, je tourne depuis 1996 avec (à l'épqoue) 512 Meg, 4 Meg, 2 Gig de mémoire..
  
  Maintenant, je fournis la possibilité de limiter la mémoire utilisée, mais je ne fais que lire la ressource.. Je ne suis pas responsable - et je ne veux pas que mon appli le soit - d'aller chercher de l'info sur la config mémoire... Ni d'en fournir.. Ni de bloquer l'écriture du fichier de config.. Mon appli a d'autres choses à faire, et je ne suis pas maître des autres processus tournant sur la machine, ni des droits d'accès accordés à tel ou tel usager sur tel ou tel fichier.. . Et ce n'est pas dans la fonctionalité de mon appli.
  
  
  
• Exemple 2 : la partie serveurs/grappes :
  
  Potentiellement chaque serveur "du bas de la chaîne" peut accèder à une base différente, dotée d'un moteur différent (Oracle, flat file, Access, autres). Chacun de ces serveurs a plusieurs types de données utilisateurs (éventuellement qui se recoupent, souvent non).
  
  Dans le code de la biblothèque sur laquels ces serveurs seront construits, j'inclue la possibilité d'optimiser le nombre de processus au détriment du temps de réponse (chaque requête démarre le serveur puis le ferme), ou d'optimiser le temps de réponse par rapport au nombre de processus (chaque serveur accédé reste "up" jusqu'à fermeture explicite (généralement fermeture de l'appli))
  
  Autant j'ai prévu ces cas, autant l'exploitation et la surveillance du nombre de processus et l'éventuelle modification du flag de lancement des serveurs dépendra du SI. PAS DE MON PROGRAMME..
  
  C'est ce que je voulais dire... La seule chose que j'ai faite c'est autoriser une optimisation du nombre. "logger" le nombre de processus n'est non seulement pas souhaitable fonctionnellement (un serveur "au milieu" peut se voir mettre en optimisation de processus, et pas celui responsable de la grappe en dessosu) , mais ce n'est pas à moi de fournir ces infos... ça dépend de ce que le SI a configuré dans les paramètres systèmes.. suivant la machine... et son utilisation...

[Melem]

euh....

Il me semble que ton argument est spécieux : si je fais une appli d'affichage de cartes, ou un visualseur MPEG, une consome MIDI, un jeu de poker, une appli de e-learning, un logiciel à destinations d'utilisateurs, en quoi ai-je besoin d'aider des experts en sécurité ??????????

Dans mon message d'avant, j'avais déjà précisé en quoi les logs pouvaient aider certains professionnels de l'informatique, notamment les admin sys. Du coup, même dans une application de type notepad, ils trouveront toujours leur utilité.

Malheureusement pour les admin sys, les développeurs n'ont pas le réflexe de penser aux logs dans l'exercice de leur métier, à moins que ça soit clairement imposé (comme dans mon cas). On est bien d'accord que c'est tout à fait normal vu que leur utilité ne nous concerne pas.

En résumé, on peut voir le logging comme une bonne pratique de programmation, peu connue des programmeurs pourtants, puisqu'il permet de générer des informations qui pourraient être utiles à d'autres personnes (autres que nous développeurs). Cependant, à cause de l'effort supplémentaire et souvent disproportionné qu'elle requiert, ainsi que de sa faible importance aux yeux des développeurs eux-mêmes, cette pratique est souvent prise en considération que par ceux qui en ressentent réellement le besoin.

Je vais ajouter 2 exemples :

Désolé mais est-ce que tu peux un peu m'éclairer sur leur pertinence dans cette discussion ? J'ai l'impression que tu as juste balancé des exemples de projet où tu n'as pas eu recours à du logging. Ma foi mais on peut chacun en balancer mille comme ça .

[souviron34]

Malheureusement pour les admin sys, les développeurs n'ont pas le réflexe de penser aux logs dans l'exercice de leur métier, à moins que ça soit clairement imposé (comme dans mon cas). On est bien d'accord que c'est tout à fait normal vu que leur utilité ne nous concerne pas.

En résumé, on peut voir le logging comme une bonne pratique de programmation, peu connue des programmeurs pourtants, puisqu'il permet de générer des informations qui pourraient être utiles à d'autres personnes (autres que nous développeurs). Cependant, à cause de l'effort supplémentaire et souvent disproportionné qu'elle requiert, ainsi que de sa faible importance aux yeux des développeurs eux-mêmes, cette pratique est souvent prise en considération que par ceux qui en ressentent réellement le besoin.
...
Désolé mais est-ce que tu peux un peu m'éclairer sur leur pertinence dans cette discussion ?

Non, ce que je dis par les exemples c'est que autant à la conception on peut penser à fournir certaines possibilités de "tuning" autant la responsabilité du "logging" des éléments sur lesquels ce "tuning" peut être fait est hors du cadre de l'appli.

Sur un système unixoide un "top" ou un "ps -ef" sera utilisé par les admins. Sur un Windows par exemple le vsualiseur de ressources, ou un autre outil..


Quant à tes 2 premiers paragraphes cités, je ré-itère : ce n'est pas du ressoirt des programmeurs d'une appli ...

En résumé, on peut voir le logging comme une bonne pratique de programmation, peu connue des programmeurs pourtants, puisqu'il permet de générer des informations qui pourraient être utiles à d'autres personnes

Non seulement c'est faux, ce n'est PAS une bonne pratique de programmation (très souvent dégradation des performances), cela nécessiterait des connaissances sur le système qui ne rentrent pas dans le cadre du travail d'un développeur "normal", mais de plus encore une fois ces informations - et leur pertinence de même que les choix des mesures - sont tellement dépendantes des systèmes et des politiques de SI qu'il serait absurde qu'un développeur en tienne compte pour faire du "logging"..

Tu fais un traitement de texte : vas-tu à chaque alloc/free aller écrire quelque part ce que tu alloues/libère ? Et si la libération n'est pas en fin de segment, elle n'a de toutes façons pas d'impact sur la mémoire du processus..

Qu'il y aie des besoins particuliers, certes, et si le soft est à utiliser en interne, et qu'on a spécifié qu'il faudrait pouvoir surveiller ceci ou cela, certes c'est inclus dans le cahier des charges.

Mais de manière générale ce n'est en rien une question de "réflexe" ou "de bonne pratique", ou de "feignasserie par raport aux efforts à fournir".. C'est hors sujet sans plus...

[Melem]

ce n'est PAS une bonne pratique de programmation (très souvent dégradation des performances)

Si c'en est une, dans l'idéal (cf les raisons que j'ai avancées), mais certes parfois coûteuse en pratique (cf la suite du message que tu t'es hâté à citer). En outre, sur la question des perfs, ça dépend de ce que l'on veut. Dans de nombreuses applis, on ne cherche pas à optimiser QUE les perfs, ou on ne cherche pas à optimiser les perfs tout court.

Tu fais un traitement de texte : vas-tu à chaque alloc/free aller écrire quelque part ce que tu alloues/libère ? Et si la libération n'est pas en fin de segment, elle n'a de toutes façons pas d'impact sur la mémoire du processus..

Ca peut arriver, par erreur bien sûr. Mais bon, pour ça il y a aussi les débogueurs, même si le logging peut aussi servir en effet à détecter ce type d'erreur (le diagnostic/débogage étant une des applications possibes du logging).

[souviron34]

bon, on va pas épiloguer là-desus, mais je ne suis pas du tout d'accord..

Dans de nombreuses applis, on ne cherche pas à optimiser QUE les perfs, ou on ne cherche pas à optimiser les perfs tout court.

On ne doit franchement pas travailler sur le même genre d'applis, alors...

[Mat.M]

Quand est-il plus avantageux d'utiliser une bibliothèque de logging plutôt que de gérer les logs soi-même ?

le plus avantageux c'est de gérer les logs soi-même désolé pour les mécontents..
pour tracer des logs en langage C, ça demande 5minutes pour créer un FILE, appeler fopen , fwrite et fermer le fichier.
Donc 100% d'accord avec Souviron34...( et tant pis pour les mécontents)
Si tu prends une biblio de logging ça va être encore une de ces innombrables usines à gaz qui vont faire grossir la taille de l'éxecutable.
Franchement je ne vois pas l'intérêt de faire une biblio de logging...

[Mat.M]

Faire du loggin de debogage avec des biblos exterrnes est de la stupidité, sauf si on utilise déjà des fonctions externes..

on est 2 à penser la même chose

[straffo]

Utiliser des logs alors que l'on a un débugger est ...

Sauf en prod mais la ce n'est plus du debug (normalement ) car il n'y a que le minimum vital de logs ce qui du coup permet rarement de débugger ...

[Melem]

le plus avantageux c'est de gérer les logs soi-même désolé pour les mécontents..
pour tracer des logs en langage C, ça demande 5minutes pour créer un FILE, appeler fopen , fwrite et fermer le fichier.
Donc 100% d'accord avec Souviron34...( et tant pis pour les mécontents)
Si tu prends une biblio de logging ça va être encore une de ces innombrables usines à gaz qui vont faire grossir la taille de l'éxecutable.
Franchement je ne vois pas l'intérêt de faire une biblio de logging...

Tu pourrais peut-être dire à la team Syslog et à Microsoft pour ses bibliothèques Windows Event Log et Event Logging d'arrêter de développer des bibliothèques de logging alors stp ? Parce que les pauvres ils bossent comme des malades sur des bibliothèques qui ne servent à rien. Oops, je me suis trompé, qui ne te servent pas toi. Surtout à Microsoft, dis-leur qu'ils sont vraiment trop c*ns de payer des gens pour développer un truc 100% inutile, que chacun peut faire en 5 minutes. Merci.

Utiliser des logs alors que l'on a un débugger est ...

Deux choses qui n'ont pas la même fonction. As-tu déjà au moins lu ce message avant de dire cela ?

[Bktero]

Accessoirement, tu peux avoir un débuggueur sur la machine développement mais dans le même temps ne pas avoir accès à la machine de production.... Belle jambe ton débuggueur, merci les logs de débug !

[souviron34]

je m'excuse c'est à cause de moi que la discussion est repartie : j'ai cité la discussion dans un autre thread désolé..

Sur vos 2 posts :

• Les bibliothèques d'event log ne servent, selon mon expérience, que dans du debug.
  
  
• Quand on en en environnement opérationnel, d'une part le minimum de log doit être fait, et deuxio si problème il y a normalement, une plateforme de test, entre le dev et l'opérationnel. Cela fait normalement partie du bug report de signaler les circonstances (éventuellement le cas précis avec valeurs, minutage, etc) d'une anomalie constatée.
  
  Et normalement on va reproduire sur l'environnement de test, avec souvent justement au départ la version opérationnelle. puis la version dev qui comprend les debugs ou traces..

[straffo]

Deux choses qui n'ont pas la même fonction. As-tu déjà au moins lu ce message avant de dire cela ?

Oui justement et alors ?
Perso ce que j'appelle debugger c'est essayer de résoudre un pb fonctionnel et fait partie du dev.

cf dernier message de souviron34.

Une autopsie est pas vraiment du même domaine et même si je ne suis pas un grand fan de l'analyse des core dump ça reste souvent plus utile que des logs ou des pb de concurrence masquent souvent la réalité.

[Melem]

Le débogeur :
- sert notamment à trouver les erreurs de programmation (problèmes d'accès en mémoire, erreur d'algorithme, etc.)
- s'utilise en phase de développement

Les logs :
- servent notamment à repérer les erreurs survenues à l'exécution (pannes matérielles, attaques, etc.), qui peuvent survenir même dans un programme "sans bogue"
- s'utilise en version finale (logiciel sur le terrain), pas en phase de développement
- Cela n'empêche pas que les logs permettent également de déboguer en phase de dev, même si ce n'est pas sa vocation (les logs peuvent donc parfois se substituer à un débogueur pour du débogage très très basique mais un débogueur ne pourra jamais se substituer à un système de log)

[Bktero]

Et normalement on va reproduire sur l'environnement de test, avec souvent justement au départ la version opérationnelle. puis la version dev qui comprend les debugs ou traces..[/LIST]

Je suis d'accord avec toi : tu dois pouvoir reproduire sur ton environnement de qualification, normalement iso-production. J'ai eu des cas (dans ma pourtant courte expérience) où ce n'était pas le cas, pour des raisons comme :

• la machine du client est beaucoup moins puissante que la nôtre
• les volumétries des BDD ne sont pas égales (pas très iso... certes)
• random problème qu'on n'a jamais pu déterminé

On doit alors blinder en logs de débug pour tenter de trouver l'origine du problème

les logs permettent également de déboguer en phase de dev

Quand j'étais arrivé dans ma précédente boite, en tant que stagiaire, on m'a dit "tout trace dont tu as besoin doit être faite dans les logs, aucun fichier personnel, aucun printf, sinon ça reste et ça fait des anomalies". Pas le choix donc sauf à prendre le risque de se faire taper si tu oubliais un debug quelque part

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

je m'excuse c'est à cause de moi que la discussion est repartie : j'ai cité la discussion dans un autre thread désolé..

Ah ben bravo !
Pour éviter de repartir dans les polémiques, ça dépend beaucoup des projets, des choix imposés faits pour le projet, des directives communes à tous les projets l'entreprise, etc (Je pense à une société telle que Bouygues Telecom qui sous-traite je ne sais combien de ST à différents prestataires, en plus des projets réalisés en interne, le tout dans des technologies multiples . N'est ce pas une bonne idée d'avoir une bibliothèque de logs traduites dans les différents langages pour facilité l'exploitation ? C'est très possible)

[souviron34]

Les logs :
- servent notamment à repérer les erreurs survenues à l'exécution (pannes matérielles, attaques, etc.), qui peuvent survenir même dans un programme "sans bogue"
- s'utilise en version finale (logiciel sur le terrain), pas en phase de développement
- Cela n'empêche pas que les logs permettent également de déboguer en phase de dev, même si ce n'est pas sa vocation (les logs peuvent donc parfois se substituer à un débogueur pour du débogage très très basique mais un débogueur ne pourra jamais se substituer à un système de log)

Franchement, je crois que ton "métier" n'est pas le coeur des métiers couverts en général..

Perso, je n'ai JAMAIS vu des logs servir de repère des erreurs survenues à l'exécution...

Uniquement pour des (éventuels) repères (indicatifs) de là où ça c'est arrêté...

Et uniqiuement indicatifs... et éventuels.. parce que bien souvent l'erreur n'a rien à voir avec l'endroit où ça s'arrête..

Mais visiblement les domaines concernés ne sont pas semblables...

• la machine du client est beaucoup moins puissante que la nôtre

Ah ? Et tu le vois sur un log ?

Et quel est le CP qui ose laisser sortir un soft ssans le tester sur la config du client ???? dans mon manuel, il est viré...

• les volumétries des BDD ne sont pas égales (pas très iso... certes)

Voir plus haut.

• random problème qu'on n'a jamais pu déterminé

On doit alors blinder en logs de débug pour tenter de trouver l'origine du problème

Alors là je rigole.. jaune..

Depuis quand un log va-t-il te donner des erreurs mémoires, des erreurs de dépassement, de collisions, ... ???? ou alors tu parlais de printf, comme je disais plus haut ? là je te suis...

A moins d'avoir mis un log par ligne de code, auquel cas c'est inopérationnel..

Un problème "random" se debug, certes, mais avec TOUS les moyens possibles, et le plus souvent c'est en ajoutant des traces là où on'avait pas pensé en mettre, en mettant en commentaire une partie du code, en enevant des fonctionalités, des chemins entre des fonctionalités..

Bref, ce genre de problème est un casse-tête où aucune méthode "figée", à moins comme je disais d'ête exhaustive et de printer chaque ligne, n'est sûre ni à utiliser seule..

D'autant plus que cela peut dépendre de DLL externes, de patch de DLL ou d'exécutables externes,.. Bref de tout un tas de trucs bizzaroides..

Ce qui doit vous arriver asez souvent si vous n'avez pas en test la même machine que le client... avec un volume équivalent...

ça m'est arrivé de passer 3 mois pour trouver un tel bug... En ayant tout essayé... Et fianelement, log ou pas, c'était que sur UNE machine parmi 80, un patch n'avait pas été appliqué sur une DLL utilisée par une DLL utilisée par une DLL utilisée par notre appli... essaye de trouver ça avec des logs..

Un bug "random" apparaît, comme son nom l'indique, de manière non reproductible..

[Melem]

Franchement, je crois que ton "métier" n'est pas le coeur des métiers couverts en général..

Perso, je n'ai JAMAIS vu des logs servir de repère des erreurs survenues à l'exécution...

Mon métier est tout simplement celui du développeur logiciel. Je n'ai jamais lu ce qu'il y a dans les logs que je génère au boulot, car je n'en ai rien à f**tre. Je me contente juste de les générer à la demande de notre admin sys, qui dit qu'il en a besoin. Après, c'est son problème qu'il en ait réellement besoin (pour prévention & détection de pannes matérielles, sécurité, etc. bref, son boulot) ou qu'il veut juste les imprimer pour se torcher .