Le développeur peut-il être remplacé par la machine ?

**skeud** · 04/07/2011, 11h36

De nos jours, on peut tout (ou presque) faire avec un outil informatique.
De plus en plus de métiers sont remplacé de manières informatique.
Actuellement, on est capable de générer du code à partir d'un autre code (compilateur qui transforme un langage en code assembleur puis langage machine).
On pourrait donc penser qu'un programme pourrait traduire du français en langage machine.

La question est:

Un programme peut-il être développé par un autre programme?

Cette question revient dans pas mal de film (I-robot,Matrix par exemple), dans lesquels des machines créent d'autre machine.

Cette question pose aussi un problème d'éthique, si des machines peuvent "procréer", peut-on les considérer comme des "êtres"?

Pour ma part je pense que cela pourrait être possible, mais aurions-nous vraiment l'intéret de le faire?

**gangsoleil** · 04/07/2011, 15h04

Bonjour,

C'est techniquement possible. Mais ca s'arrete la.

En effet, tous ceux qui ont pu voir des cahiers des charges savent bien qu'entre ce que veut le client, ce qu'il demande, ce qu'il ecrit dans le cahier des charges, et ce qu'il te dit au cours du developpement, ca n'a rien a voir.

Le temps passe a etablir un cahier des charges "compilable" serait probablement plus important, ou au moins aussi long et cher, que de faire developper le code par des humains.

**davcha** · 04/07/2011, 22h19

J'ai programmé il y a quelques temps durant mon temps libre un énumérateur de "machine de turing"... En fait, c'était plutôt basé sur le lambda-calcul, mais c'est exactement la même chose.

A côté de ça, j'avais mit en place un système de contrainte qui permettait de définir ce qu'on voulait... Mais c'était très loin d'être au point.

Par exemple, pour définir l'opérateur successeur (+1 quoi), j'avais une série de contrainte, par exemple :
0 -> 1
1 -> 2
2 -> 3

Et ça marche très bien hein. Le programme te sortait un lambda-terme (donc un algorithme) qui satisfaisait à la contrainte.
Le problème, c'est que, tu lui passais 3, il te renvoyait n'importe quoi.
C'est à dire qu'avec la contrainte ci-dessus, t'avais pas l'opérateur +1, mais la fonction qui associe 1 à 0, 2 à 1, 3 à 2, etc...

Le gros problème en fait est : comment définir une contrainte qui réponde vraiment à ce qu'on veut (successeur), sans donner l'algorithme du successeur...

Parce que l'ordinateur doit être capable de vérifier que l'algorithme testé réponde bien à ce qu'on veut. Mais pour faire ça, il faut qu'il puisse tester et comparer l'algorithme avec quelque chose qui se comporte comme ce que devrait faire l'algorithme recherché. Or, ce quelque chose, c'est l'algorithme recherché.

A côté de ça, il y a un 2e problème au moins : celui de l'arrêt.
En gros, c'est pas parce que ton algo donne pas le bon résultat rapidement qu'il ne le donnera pas plus tard (si tant est qu'il soit encore en cours d'exécution).

Bref... On peut clairement pas tout faire dans ce domaine en tout cas. On ne pourra se limiter qu'à une partie de l'ensemble.

**nah666** · 05/07/2011, 17h36

On pourrait donc penser qu'un programme pourrait traduire du français en langage machine.

Comme nous le voyons tous les jours dans notre travail de traduction de spécifications en programme, il y a un un grand nombre de points non précisés qui demandent à être tranchés ou indiqués.

Dans l'absolu il est possible de réaliser un programme qui va traduire le français en langage machine, mais tu devra être tellement précis dans cette spécification qu'au final ... tu fera du code.

**zaventem** · 05/07/2011, 20h30

Est-ce qu'un développeur peut être remplacé par la machine?
Oui certainement, il suffit de voir certains générateurs de code qui automatisent de façon plutôt pas mal une partie de la programmation.

Est-ce que l'on pourra un jour construire des solutions entières en se passant de développeurs, j'en doute.

**Chatanga** · 05/07/2011, 21h34

C'est un peu confus.

Si on parle de traduire un algorithme exprimé sans ambiguité du français (ou une autre langue naturelle) vers un langage formel, la réponse est oui. Il faudra juste une personne (qu'on appellera un développeur) pour trouver la formulation sans ambiguité.

Si on parle d'un algorithme capable d'en produire un autre, la réponse est évidemment oui et ça n'a rien de sensationnel s'il n'y a pas plus de contraintes.

Si on parle d'un algorithme capable d'en produire un autre qui résout un problème donné quelconque (pas un sous-ensemble bien délimité donc), la réponse est connus depuis pas mal de temps et c'est non : cf. le théorème de Gödel.

Une question plus intéressante serait : "que possède l'homme qui lui permette d'imaginer des solutions et qu'un algorithme ne possède pas ?". Roger Penrose répondrait la conscience. Peut-on construire une machine artificielle pensante ? On ne sais pas encore (sans-doute que oui, ce serait un peu frustrant sinon). Quant à savoir si on devrait le faire une fois en mesure de le faire, c'est aussi une bonne question... Personnellement, je n'hésiterais pas. Il n'y a pas de raison de se limiter à ce que la nature nous a donné, y compris en terme de reproduction. La frontière ne sera d'ailleurs probablement pas stricte entre humains et machines. Le biologique n'est qu'une forme de mécanique très évoluée et on commence déjà à jouer avec des solutions biomécaniques (transistors organiques, organiques artificielles, etc.). J'imagine aussi que la transition ne se fera pas d'un seul coup. On devrait savoir étendre le cerveau humain avant de le dupliquer (implants mémoires avec des neurones de synthèses par exemple), modifier le génomes de nouveau-nés pour leur permettre de vivre sous les océans ou dans l'espace (des corps différents produisent aussi des esprits différents aux pensées différentes), etc. Bref, en 2019 la question ne sera pas de savoir si on est un humain ou une machine, mais plutôt si on est suffisamment riche (pour améliorer son corps biomécanique et son esprit augmenté) ou trop pauvre (pour soigner ses poumons ou réparer son injecteur d'huile).

**gorgonite** · 05/07/2011, 21h48

il ne faut pas oublier aussi la "programmation graphique", on décrit des modèles avec des relations et des contraintes, et une chaîne de compilation dédiée effectue le restes... alors clairement ce n'est pas un cahier des charges, mais ça reste plus compréhensible pour un non-développeur : ex pour les controle-commandes avec des outils orientés automaticiens

**skeud** · 06/07/2011, 09h41

La question que je me pose surtout c'est:

Si on arrive bien à réaliser notre programme, en demandant au client comment il veut que ça fonctionne, pourquoi une machine ne pourrait pas en faire autant?

Il m'arrive souvent, lors de la création d'algorithme, de me demander:
"Comment je ferais moi-même?"
Et de reproduire ma démarche en code.
On pourrait donc se poser la question, comment je fais pour coder?
Et reproduire notre démarche en code.

Si on programme un logiciel qui pose ces questions auxquelles le client répond, on pourra générer le code correspondant. Là où ça posera des problèmes, ce sera pour le design, une machine ne peut que reproduire, pas inventer.

Ensuite effectivement, il faudra des développeurs pour créer de tel programmes. De la même manière on a besoin de pilote pour conduire les machines qui remplacent les ouvriers.

Conclusion, on pourrait réduire l'effectif de moitier grâce à une tel technologie.
Chose qui plairait à pas mal de pdg je pense.

(mais pas à nous, pauvre codeur)

**souviron34** · 06/07/2011, 13h13

Envoyé par skeud

Si on programme un logiciel qui pose ces questions auxquelles le client répond, on pourra générer le code correspondant. Là où ça posera des problèmes, ce sera pour le design, une machine ne peut que reproduire, pas inventer.

Là où tu te goures, c'est que même algorithmiquement, il peut y avoir plusieurs solutions à un problèmes, solutions qui ont certains avantages par rapport à d'autres, et qui, en l'absence d'autre chose comme entrée, deviennent indécidables..

D'excellents exemples se trouvent partout en algorithmie géométrique : entre économe de mémoire, économie de vitesse, économie de complexité, économie pour des calculs ultérieurs, hypothèses sur la répartition des données initiales, etc etc, le même but peut être atteint par diverses solutions...

Sans une intervention humaine qui "hiérarchise" les priorités (et ceci est au cas par cas en général), impossible de choisir "le bon" algorithme...

Par exemple un tri... Mais on peut aussi penser aux algorithmes d'enveloppes convexes, au plu court chemin, etc etc..

Ce qui fait la force de l'intervention humaine, c'est justement de prendre en compte des contraintes non-quantifiables facilement (comme pour le design)... Et d'avoir des "associations d'idées" à la base de la plupart des algorithmes importants...

**Ubiquité** · 06/07/2011, 13h26

Fondamentalement être développeur c'est traduire des spécifications exprimées en langage naturelle (écrite, oral, peu importe) en langage formel compréhensible par la machine.
Donc on peut se passer de développeur si on peut écrire les specifiquation en langage formel sans lui. Pour cela il faut un langage de programmation (le langage formel) suffisament simple pour que tout le monde le maitrise.

**skeud** · 06/07/2011, 14h03

Envoyé par souviron34

Là où tu te goures, c'est que même algorithmiquement, il peut y avoir plusieurs solutions à un problèmes, solutions qui ont certains avantages par rapport à d'autres, et qui, en l'absence d'autre chose comme entrée, deviennent indécidables..

Je suis d'accord mais pour décider, on utilise bien une logique, hors l'ordinateur est logique lui aussi, il suffirait de lui donner cette logique de la même manière qu'on nous la donne, pour qu'il puisse faire le choix.

Envoyé par Ubiquité

Donc on peut se passer de développeur si on peut écrire les specifiquation en langage formel sans lui. Pour cela il faut un langage de programmation (le langage formel) suffisament simple pour que tout le monde le maitrise.

A force de simplifier de plus en plus les langage (ie langage bas niveaux -> langage haut niveau) on finira bien par arriver à un résultat proche de ce que j'explique

**davcha** · 06/07/2011, 15h09

Envoyé par skeud

A force de simplifier de plus en plus les langage (ie langage bas niveaux -> langage haut niveau) on finira bien par arriver à un résultat proche de ce que j'explique

Ca serait bien étonnant.

La simplification des langages dont tu parles est surtout due à l'abstraction du matériel, de l'aspect purement technique des logiciels.
Exemple tout bête : les pointeurs. Les pointeurs c'est une notion liée à la façon dont fonctionne la mémoire d'un ordinateur.
Change la mémoire en accès aléatoire par une mémoire qui fonctionne comme une pile, et tu n'as plus besoin de pointeurs.

Si tu fais totalement abstraction du matériel, que tu ne gardes que la logique... Que les maths autrement dit...
Ben, même en maths tu as plusieurs manières de résoudre un problème, de valider ou invalider une proposition, etc...

Et quand tu sais que rien que l'arithmétique de base induit déjà des soucis comme l'incomplétude de godel... bah voilà quoi.

**skeud** · 06/07/2011, 15h23

Envoyé par davcha

Ben, même en maths tu as plusieurs manières de résoudre un problème, de valider ou invalider une proposition, etc...

Et pour trouver la meilleur manière, tu teste ou tu te pose la question, quelle serait la meilleur manière.
Ces question trouve des réponses logique donc techniquement, une machine pourrait y répondre à ta place ^^

**souviron34** · 06/07/2011, 15h57

regarde par exemple :

Convex hull algorithm

Non seulement pour un seul et même problème assez simple, il y a pleins d'algos possibles, mais même passer de l'idée de base de l'algo a sa programmation n'est pas trivial.

De plus, il y a des variantes pour chacun, chacune avec ses avantages et inconvénients...

Et même cette page ne cite que les plus courants, il y en a pleins d'autres. Même en prenant des hypothèses ultra-restrictives (polygone simple), et même en prenant une complexité déterminée (linéaire) on trouve :

A History of Linear-time Convex Hull Algorithms for Simple Polygons

Si donc je veux dire :

"trouver le polygone convexe entourant cet ensemble de points avec une complexité linéaire", j'ai déjà un gros problème... (même la solution disant "on fait comme en entourant un paquet avec du papier")

Et si tu regardes en détail ces pages, tu verras qu'entre l'idée parfois simplissime de l'algo et le code correspondant, c'est complexe...

Même chose si on regarde la triangulation de Delaunay ou le diagrammme de Voronoi, pourtant tous les 2 très fortement utilisés..

C'est tout ce qu'on veut dire : dans la majeure partie des cas, il n'y a pas de chemins simples et logiques "sans équivoque" pour aller de A à B, surtout pour passer de "A" à "code pour aller à B"..

**fregolo52** · 06/07/2011, 18h11

Envoyé par skeud

Cette question revient dans pas mal de film (I-robot,Matrix par exemple), dans lesquels des machines créent d'autre machine.

Tu as oublié le meilleur de tous, mais c'est peut-etre ta jeunesse qui fait ça !!

Terminator et SkyNet !!!!

**zaventem** · 06/07/2011, 23h35

Envoyé par skeud

Si on programme un logiciel qui pose ces questions auxquelles le client répond, on pourra générer le code correspondant. Là où ça posera des problèmes, ce sera pour le design, une machine ne peut que reproduire, pas inventer.

il y a un an ou deux, j'ai eu l'occasion de tester un outil de Business Process Modeling qui générait automatiquement une grande partie du code de l'application avec très peu d'intervention technique de l'IT (le principal travail consistait à lier les données métiers aux champs de la base de données). Le résultat était plutôt pas mal mais cela a un prix.

Les processus métiers doivent être définis rigoureusement dès le début et de manière très formelles. Cela a une valeur ajoutée pour le métier en offrant des processus documentés de manière complète et cohérente dans l'ensemble de l'entreprise mais le travail pour ce faire est colossal
Quand les processus sont complexes et fortement non-linéaires, on évite pas de mettre les mains profondément dans le cambouis et la complexité des développements sont alors souvent plus compliqués.
L'architecture de la solution est largement dictée par la solution. Si celle-ci n'est pas mauvaise en soi, cela peut poser problème par exemple lorsque qu'un même traitement doit être tantôt exécuté à la demande cas par cas, tantôt exécuté en batch sur un grand nombre de données.

Cela fonctionne dans des applications de gestion telles que gestion d'inventaire, gestion des clients,... mais c'est encore loin d'être une solution universelle.

En fin de compte, si le seul but est de générer automatiquement l'application, je trouve que l'intérêt est très limité: le travail de modélisation et de spécification en amont est tel qu'une fois qu'il est fait, le développement en lui même ne représente plus qu'une "simple" formalité.

**souviron34** · 07/07/2011, 02h08

J'ahouterais que le seul cas où c'est simple c'est :

Envoyé par skeud

Si on programme un logiciel qui pose ces questions auxquelles le client répond, on pourra générer le code correspondant.

ça c'est un système expert..

J'ai eu le cas avec le Département de la Protection à La Jeunesse : un soft fait pour que les intervenants puissent décider si le gamin rentrait dans la catégorie "sévices", "à surveiller", "trè dur", "à signaler", etc tc...

Tout ce que ça faisait c'était poser dans l'ordre les questions de la loi, et aiguiller suivant les bons aiguillages au fur et à mesure..

Mais au-delà de ça, et comme le dit Zaventen, à part des champs d'actions très limités, c'est irréaliste pour des questions et de coût et de complexité des phénomènes / demandes / possibilités / algorithmes / décisions ...

**skeud** · 07/07/2011, 09h25

Envoyé par fregolo52

Tu as oublié le meilleur de tous, mais c'est peut-etre ta jeunesse qui fait ça !!

Terminator et SkyNet !!!!

voila terminator, je savais bien que j'en oubliais un

Par contre connais pas skynet, je sais quoi regarder ce soir

Peut-être est-ce du à ma jeune expérience, mais j'étais persuader que coder un programme qui en code un autre en fonction des demandes était réalisable, certe ça prendrait pas mal de temps (en année bien sur).

Je me mets souvent a la place de l'ordinateur lors de la création d'un programme, pour savoir comment faire tel ou tel chose, et à chaque fois je prend des décision logique choisi par des paramètre quantifiable.
J'agis comme une machine en quelque sorte

, donc une machine aurait pu agir comme moi