Mettons que vous embauchez quatre peintres, des artistes qui sont sensés savoir dessiner, dont c’est leur métier, et que vous leur proposez un « défi » un peu particulier : celui de dessiner un tableau en commun, contenant « un cheval », mais pour pouvoir le terminer le plus vite possible (rentabilité) il faut que tout le monde puisse travailler en même temps sur le même tableau. La toile sera ainsi découpée en quatre zones pour que chacun puisse dessiner indépendamment des autres la partie qui lui incombe : la tête, le dos, les pattes avant et les pattes arrière.

Au final, en supposant que vous êtes tombé sur une bonne équipe, qui communique bien ensemble (ils arrivent au moins à se mettre d’accord sur qui fait quelle partie), vous obtiendrez, au mieux, quelque chose qui ressemblerait très certainement à ceci : Ok, c’est bien un cheval, mais vous allez dire que c’est un peu particulier quand même… On distingue clairement une différence de style entre chaque partie, ce qui le rend peu harmonieux : des incompréhensions, des endroits où ça ne « colle pas vraiment », ou « rafistolés pour que ça colle », ou pas finis, voir même « vite fait » ou « mal fait », etc…

Eh bien, aussi étonnant que cela puisse paraître, derrière ces ordinateurs à priori « si parfaits et cartésiens », nous les informaticiens et surtout les développeurs logiciel, aussi scientifiques dans l'âme que nous puissions l'être, fonctionnons exactement de la même manière : nous sommes des artistes !

En effet, comme chacun de ces quatre peintres, nous avons notre « style » personnel, notre façon de « dessiner » (coder) un programme informatique (logiciel). Chaque informaticien a donc sa manière particulière d’engager sa créativité débordante (n’en doutez pas !) pour résoudre un problème : des points auxquels nous faisons plus attention que d’autres, des détails qui nous paraissent plus ou moins importants, des façons de faire, des techniques à appliquer, des méthodes, et en somme des approches tout à fait différentes pour réaliser exactement le même travail… Toutes basées en fin de compte sur notre (in)expérience, notre vécu, voir même notre caractère, qui définissent notre personnalité, exactement comme un artiste !

A l’instar d’un artiste auquel un client passe une commande particulière, que ce soit un peintre avec ses pinceaux et sa palette face à sa toile ou d’un sculpteur avec son marteau et ses burins face au bloc de pierre, nous avons nos outils équivalents : les langages et environnements de programmation. Et tout comme un sculpteur qui dégrossit sa pierre ou un peintre qui dessine « les grands traits » de son tableau, nous concevons d’abord « les grands traits » (conception, spécification) de l’application que nous allons programmer. Mais, toujours comme un artiste, nous avons besoin de savoir ce qui est attendu : un cheval ? D’accord, mais debout ou couché ? En pleine course ou à l’arrêt ? De quelle couleur ? De quelle race ? Et puis, à l’instar du sculpteur, nous commençons par « dégrossir » (architecture logicielle, modules fonctionnels, etc…) pour finir par rentrer dans les détails (codage), rencontrant alors des nouveaux problèmes qu’on n’avait pas vus dès le départ : comment tailler sa crinière qui vole au vent sans casser la pierre ? Mais au fait, faut-il sculpter un mâle ou une jument ?

Enfin, tout comme les artistes nous subissons des contraintes, hors mis la commande en elle-même (« je veux un cheval », donc pas un éléphant ni un autre animal), le peintre ne peut déborder de sa toile et doit s’adapter au type de peinture qu’il utilise (à l’huile, aquarelle, etc…), le sculpteur ne peut déborder de son bloc de pierre initial, ne peut pas rendre la pierre « molle » à un endroit précis, même si cela l’arrangerait beaucoup… L’informaticien développeur doit aussi faire face à la technologie qu’il utilise, les normes imposées, la qualité exigée... A l’instar d’un écrivain, qui est aussi un artiste, l’informaticien doit pouvoir aussi être en mesure de modifier son « livre » si on lui demande soit une « suite à l’histoire » (nouvelle version) soit de corriger des erreurs (bugs : mise à jour) dans un chapitre… Par ailleurs, saviez-vous que le « code » écrit (produit) par un informaticien est protégé par les droits d’auteur au même titre qu’un livre ? Intéressant non !

Ça a l’air déjà compliqué comme ça, mais si en plus vous ajoutez le fait que de nos jours il faut souvent être non pas 4 comme au début sur le tableau du cheval mais entre 10 et 50 artistes (parfois même bien plus !) pour construire un même ouvrage en un temps record, que la moitié d’entre eux sont à l’autre bout du monde et ne parlent pas votre langue et que celui qui a passé commande (le client) a juste demandé « je veux un cheval, vous vous débrouillez pour que ce soit un cheval, je m’en fous du reste », mais qu’au final il voulait une licorne ailée avec un arc en ciel… Vous pouvez imaginer le bordel que ça doit faire !!!

Eh bien oui, l’informatique, surtout le développement logiciel, de nos jours c’est ce joyeux bordel là : essayer de faire travailler ensemble beaucoup d’artistes sur une œuvre commune souvent mal définie, avec toutes les différences de considération et d’approches que cela contient… Pas facile hein… pourtant on y arrive !


En conclusion de ce premier article concernant ce que j’appellerais ma « théorie du tableau », si vous êtes informaticien ou que vous gérez des informaticiens, et que vous prenez en compte cette « dimension artistique » dans votre travail, vous serez peut-être plus tolérant vis-à-vis des autres informaticiens qui ne pensent pas comme vous, car au final vous pouvez faire autant de tableaux différents d’un cheval qu’il y aura d’artistes pour les faire, pensez-y !


L’informatique : nous sommes des artistes !