Le Seb sur le Ouaibe

Un des tous premiers concepts à retenir, c'est pourquoi faire simple quand on peut faire compliqué ?.
Où pourquoi utiliser la ligne droite qui sépare le besoin A de la ressource B, quand il est possible de faire d'abord un saut sur C, d'envoyer le résultat vers D et au final d'échouer lamentablement rendu sur E ?
Tout simplement parcequ'une usine à gaz, ça en jette !

Exemple :
L'utilisateur - Bonjour, je voudrais pouvoir effectuer une requête dans la base de données X utilisée par mon application depuis mon poste de travail
L'informaticien de service - L'éditeur de l'application ne pourrait-il pas intégrer ça dans l'application ?
L'éditeur de l'application - Pas très chaud, faudrait revoir pas mal de code.
L'informaticien de service - Sinon, on peut faire une petite page CGI sur notre serveur web existant, qui interroge directement la base de données à partir des critères spécifiés. On peut aussi prévoir un export CSV pour l'interface avec Excel.
L'éditeur de l'application - On va plutôt monter un serveur web dédié qui interrogera la base via une applet Java, et utilisera des contrôles ActiveX pour s'interfacer directement avec Excel.
L'utilisateur - Ça couterait combien à développer ?
L'éditeur de l'application - 7500 € pour le développement, prix du serveur web et des licences en sus.
L'informaticien de service - Bah, une journée de boulot tout au plus.
L'utilisateur - Hum, ça me tente bien cette solution Java/ActiveX.
L'informaticien de service - Et merde ...

Deuxième concept (lié au premier) : ça ne fonctionne pas, c'est tombé en marche.
Vus la lourdeur et la complexité de certaines applications, il est souvent impossible de savoir pourquoi ça fonctionnait à un instant t, mais plus maintenant.

Exemple :
L'utilisateur - Bonjour, mon application elle ne fonctionne plus !
L'informaticien de service - Tout à l'air normal pourtant. On va essayer de relancer les services ...
(10 minutes plus tard, le temps d'essayer de remettre la main sur le gars qui a écrit la procédure de démarrage qui ne fonctionne pas)
Le gars qui a écrit la procédure - Je ne comprends pas, ça devrait fonctionner.
L'informaticien de service - Étrange, n'est-il pas ?
Le gars du réseau (tout content) - Vous ne croirez jamais ça les gars ! Ça fait deux ans qu'un de nos équipements réseau de secours était mal paramétré, je viens de m'en rendre compte. On a eu chaud !
Le gars qui a écrit la procédure - Hum.
L'informaticien de service - Le fond de l'air est frais.
Le gars du réseau (perplexe) - Un problème les gars ?
L'informaticien de service - Tu voudrais pas revenir sur la situation de départ des fois ?
Le gars du réseau (navré) - Bah ...
(10 minutes plus tard, le temps pour le gars du réseau de remettre tout comme c'était avant)
L'utilisateur - Super, ça fonctionne ! Merci.
L'informaticien de service - De rien, c'était fastoche.
Le big boss du service informatique - Va falloir régler ce problème d'application qui ne fonctionne pas avec l'équipement de secours L'informaticien de service - Et merde ...

Troisième et dernier concept (lié au second) : moins ça reboote, mieux tu te portes.
Ou pourquoi tu sais avant même de l'arrêter que ce serveur t'emmerdera à son redémarrage.

Exemple :
Le big boss du service informatique - Bon les gars, coupure électrique générale ce week-end, faudra arrêter tous les serveurs.
Les gars (navrés) - Et merde ...
(le lundi suivant la fameuse coupure électrique générale)
L'utilisateur - Bonjour, mon application elle ne fonctionne plus !
L'informaticien de service - Chié ...
(un peu plus tard dans la journée)
Le technicien d'exploitation - Tiens, on a eu une remontée d'alerte concernant un CPU H.S. ...
L'informaticien de service - Oh ...
Le technicien d'exploitation - ... et puis une autre à propos d'une barrette de RAM morte ...
L'informaticien de service - ... la ...
Le technicien d'exploitation - ... sans compter que toutes les sauvegardes du week-end se sont vautrées.
L'informaticien de service - ... grosse ...
L'utilisateur (malicieux) - Il faudrait absolument me restaurer les données de dimanche !
L'informaticien de service - ... merde !

Et voilà Coco, si jamais l'aventure de l'informatique^[1] te tente, n'oublie jamais qu'un bon informaticien se doit d'être fainéant comme une couleuvre et rusé comme un renard (pour pas se faire gauler quand il ne veut pas bosser).

La semaine prochaine, je t'expliquerai pourquoi, quelquefois, quand tu écris quelque chose important, ton clavier se blo