Un retour sur un article qui m’a fait réagir : http://tcz.hu/the-future-of-programmers
L’idée est en gros de dire que la prochaine révolution industrielle va supprimer les métiers de docteurs et de conducteurs de véhicules, et que nous autres programmeurs seront les prochains, mais que nous aurons l’honneur de participer à cette destruction de métier en créant les logiciels qui vont nous remplacer.
L’auteur utilise ensuite comme illustration de son propos le fait qu’un programme est désormais capable d’analyser une règle métier écrite en texte, et de décomposer ce langage naturel en une arborescence de sujets, de conditions et d’actions. Il utilise pour cela un excellent exemple graphique, que je me permets de recopier de son article (source citée plus haut) :
Jusque là, on est dans de la démonstration logique. Mais le saut à la conclusion est un peu abrupt : “How difficult is it to translate this into a computer program now?”. Ben, justement… c’est ça qui est difficile, et pas le reste. Parce que découper un texte correctement formaté en atomes reconnaissables et appliquer des actions dessus, c’est ce que font les moteurs de règles depuis 15 ans déjà !
Or, ce qui fait un “programme”, c’est justement tout ce qu’il y a autour et qui est incommensurablement plus difficile :
- Tenir compte des règles non exprimées (tout client d’un éditeur de logiciel commence toujours par lui dire que son métier est simple… jusqu’à ce qu’on l’analyse ensemble et qu’il réalise que son métier est complexe, et qu’il ne lui apparait comme simple que parce que son expérience fait qu’il réalise inconsciemment 90% des tâches).
- Tenir compte de règles floues.
- Réfléchir au parcours ergonomique pour les utilisateurs.
- Savoir régler les problèmes indirectement liés au programme : robustesse, sécurité, performance, etc.
- Penser en termes holistiques, c’est-à-dire pas seulement au programme en lui-même comme silo étanche, mais en tant que bloc communiquant d’un Système d’Information. La valeur est désormais plus dans les interconnexions que dans les atomes du SI.
Au passage, c’est d’ailleurs pour cela qu’il est incomplet que dire que la data vaut de l’or : tant qu’elle reste dans son programme d’origine, elle n’en a pas, et n’en acquiert que lorsqu’elle est partagée, d’où l’importance économique de l’Open Data. Vous ne croyiez tout de même pas que l’Etat publiait de la donnée ouverte juste pour des raisons de transparence envers les citoyens ?
Bref, quand on me montrera un programme qui est capable d’analyser les conversations d’un comité de vingt personnes et d’en sortir une norme de communication informatique qui traite tous les cas d’usage évoqués, je reconnaitrai que le métier de développeur est mort. Mais je pense que je le serai bien avant…
