Participer à un projet

Roschan · Le 28/02/2018, à 14:54

Le JS c'est vraiment un langage de crado et ça, ça me déplait.

Rien n'empêche de coder proprement dans un langage crado

Sinon, je ne suis pas vraiment d'accord avec ta division "itératif/objet" :
Déjà parce que le mot que tu voulais était "impératif", et surtout parce qu'aucun langage courant n'utilise exclusivement un seul paradigme : par exemple le python et le JS, à la base c'est impératif, mais en pratique dès que ça dépasse 20 lignes, ça devient vite très lourdement orienté objet (self.truc en python, this.machin en js, etc.)
Le paradigme de programmation favorisé par le langage a au final assez peu d'impact sur le mode d'exécution que ses concepteurs favorisent. Par exemple l'OCaml, qui est en partie orienté objet et en partie orienté fonctionnel, on peut l'interpréter, ou bien en faire du bytecode, ou bien en faire des binaires.

Tu peux très bien faire du C scripté. C'est juste que t'auras un script compilé en sortie

Ça c'est un contre-sens, la définition même d'un script c'est qu'il s'agit d'un programme en langage interprété, indépendamment du paradigme de programmation utilisé.

Dernière modification par Roschan (Le 28/02/2018, à 14:57)

shoot76 · Le 28/02/2018, à 15:08

Merci pour la rectification c'est en effet ce que je voulais dire ^^

Je suis navré Roschan, mais il est tout à fait possible d'écrire du script en C. (Inline C par exemple).

Quant à ton affirmation "aucun langage n'utilise un seul paradigme". Je pense que c'est faux. Java supporte que de l'objet. Les dernières versions tendent à ajouter un peu de fonctionnel. Mais ça reste de l'objet. Haskell, lui, est fait pour du fonctionnel, et pas de l'objet. Tu ne peux pas écrire d'impératif en Java tout simplement parce que la fonction principale est elle même inclue dans une Classe Main ^^

J'ai vu des scripts Python qui dépassaient allègrement les 500 lignes. La conception d'un script tient surtout de son développeur. Si tu es plutôt Objet, ton script va prendre une tournure objet. Si tu as l'habitude de faire du script, tu peux facilement faire un script de plusieurs centaines de lignes. Exemple : j'ai bossé sur un projet en C avec des gars (moi le premier) habitués à l'objet. Je te promets qu'en voyant le code, t'avais pas l'impression que c'était du C, mais du C++. C'est d'ailleurs la première remarque qu'on nous a fait sur ce projet.

Tout dépend du mec derrière le clavier en fait. Et puis, le choix d'un langage au final, ça revient vraiment à une question de goûts. C'est un peu comme dire que moi je préfère Fedora et toi Debian. Le noyau reste le même. Tu préfères les M&M's rouge ou jaune ? La vraie question c'est compilé/interprété et encore, souvent, on a aucune raison de s'en soucier. Seule la finalité du projet compte. Alors autant que la personne qui passe des heures à bosser dessus se sente bien. Après t'as les SSII qui viennent faire de la lèche au client et là, c'est une autre histoire... tu peux te retrouver à faire du Pascal ou du Cobol à la moindre occasion !

minizebr95 · Le 28/02/2018, à 21:00

Nuliel · Le 28/02/2018, à 21:13

Les M&M's jaune

Dernière modification par Nuliel (Le 28/02/2018, à 21:14)

nam1962 · Le 28/02/2018, à 21:17

shoot76 a écrit :

(...) Après t'as les SSII qui viennent faire de la lèche au client et là, c'est une autre histoire... tu peux te retrouver à faire du Pascal ou du Cobol à la moindre occasion !

Et même pas du Fortran ? Tout se perd ! Même les SSII n'ont plus d'imagination, alors...
Et le Go dans l'histoire ?

Dernière modification par nam1962 (Le 28/02/2018, à 21:24)

Roschan · Le 28/02/2018, à 21:32

La conception d'un script programme en général tient surtout de son développeur.

Oui, donc rien n'empêche de faire contenir tout un programme dans la class main d'un fichier Java, auquel cas ce sera bien orienté impératif (des affectations, des while, des for, des séquences d'instructions, ... mais zéro interaction entre objets, ni attributs, ni méthodes) et la classe principale déclarée serait alors une simple syntaxe, pas plus absconse que le main d'un fichier C/C++

Dernière modification par Roschan (Le 28/02/2018, à 21:32)

nam1962 · Le 28/02/2018, à 21:43

Wé, Roshan, bon, après, quand tu dois faire, tu es comme les autres

moths-art · Le 28/02/2018, à 22:33

shoot76 :

Difficile de résumer Rust en quelques lignes.
C'est un nouveau langage assez pragmatique : il réutilise que des concepts éprouvés (d'ou le nom).
C'est orienté bas niveau (pas de VM ni de Garbage collector) avec une gestion très fine de la mémoire :
donc notion de pointeur, donnée stocké sur le tas ou pile etc.
La grande spécificité de Rust c'est la notion de durée de vie : c'est assez contraignant pour le débutant mais à l'usage c'est très puissant.
Par rapport à du C/C++ : ça évite tous les erreurs de segmentation, buffer overflow et autre joyeuseté tout en garantissant des performances équivalentes.
Rust est un langage impératif avec beaucoup de fonctionnel : pattern matching, inférence de types, closures etc.
Niveau généricité, c'est plus puissant que le C# tout en détectant plus de disfonctionnement à la compilation.
Néanmoins, y'a pas de notion de paradigme objet.
Pas de notion d'exception : soit réussite soit erreur
Les variables sont toutes constantes par défaut. (immutable)
La notion de propriété nullable n'existe pas. (et ça évite une paire de soucis : je fais du C# au boulot et je révererais de ce fontionnement)
C'est Batterie include :
- UTF-8 par défaut
- s'interface très bien avec le C (binding facilité et/ou API C)
- Le deadcode provoque des warnings
- On peut rajouter des tests unitaires ou des benchmarks sans libs supplémentaires
- On peut documenter son code via des commentaires avec les balises du markdown : un outil permet de le compiler en html.
- concurent : même si il y a encore des grosses lacunes en ce sens, y'a des avantages certains par rapport à du C/C++

Pour les défauts : le langage est jeune et par conséquent les libs encore plus.
Y'a quasiment pas de doc en français.
Pas d'IDE dédié
Le compilateur est encore mal optimisé donc les temps de compil sont long.
La courbe d'apprentissage est longue et je déconseille d'attaquer Rust sans avoir des bases solides dans d'autre langages.

Voici quelques softs populaires écrit en Rust : https://mothsart.github.io/applis-rust.html
Je pense qu'à l'avenir il y aura beaucoup de code critique (open-source) écrit en Rust : noyau, base de données, temps réels, couche réseau, moteurs de jeux etc.
Comme dis, il se veut très strict à la compilation ce qui lui donne un avantage indéniable sur le C et C++ qui sont bien trop permissif à mon sens.
Ces derniers nécessitant Gdb, Valgrind et autres astuces du pauvre pour obtenir un soft stable.
Pour ceux qui veulent un tour d'horizon rapide, je conseil https://blog.guillaume-gomez.fr/Rust

shoot76 · Le 01/03/2018, à 10:09

nam1962 a écrit :

shoot76 a écrit :
(...) Après t'as les SSII qui viennent faire de la lèche au client et là, c'est une autre histoire... tu peux te retrouver à faire du Pascal ou du Cobol à la moindre occasion !
Et même pas du Fortran ? Tout se perd ! Même les SSII n'ont plus d'imagination, alors...
Et le Go dans l'histoire ?

Malgré ma faible expérience en SSII, j'avoue ne pas avoir eu cette chance. Par contre, niveau connerie, on m'a fait animer une formation sur PowerPivot. Une extension d'Excel. La vérité, c'est que je n'avais jamais utilisé Excel. J'ai eu beau le dire au commercial, il m'a gentiment dit de me former sur internet. Voilà le doux esprit des SSII. On répond au client. Même pour lui servir de la merde. Et le pire, c'est qu'au final, ça passe. Parce que comme je fais bien mon boulot... les gens en formation était content alors que j'en savais pas plus qu'eux.

Le Go j'en ai fait à titre perso. Franchement, j'adore. C'est une sorte de doux mélange entre du C et du python. Y'a l'aspect compilé qui rend le code méchamment optimisé (et ça, c'est jouissif quand t'as une API qui répond en quelques µs ...) et malgré tout, la syntaxe reste "sexy". La compilation est très rapide (comparée à celle du C) et génère potentiellement autant d'exécutables qu'il y a de systèmes. Avec une commande, je peux produire pour X86, 64, ARM, PowerPC...
Le gros gros point fort de Go, c'est la concurrence; C'est natif. Si t'as une instruction à paralléliser, il suffit de préfixer l'appel par "go" et c'est lui qui gère tout tout seul! Donc vraiment très puissant.

Maintenant côté négatif : Quand tu as fais de l'objet pendant 5 ans et que tu te lance dans Go, c'est déroutant. C'est pas de l'objet, ça reprend les concepts du C avec des structures. ça demande à s'habituer. Go impose son style de code. C'est pratique parce que lire du code de quelqu'un d'autre, ça changera rien vu que c'est imposé. Par contre, si t'as pas pour habitude de coder de telle manière, c'est chiant.

Me prononcer sur Go... très honnêtement, c'est un langage super sexy. Je pense que ça plaira à beaucoup de développeurs car ça répond à des problématiques techniques complexes (la concurrence) et avec un code optimisé et multiplateforme nativement. Maintenant, c'est un langage marginal comparé aux mastodontes Java/Python/C++/JavaScript. Go a eu la défaveur de sortir en même temps que NodeJS. On connait la hype qui tourne autour de ce langage. NodeJS est l'exact opposé de Go en l'essence... C'est pas compilé, c'est pas optimisé, le code est libre (on peut faire un truc propre comme dégueu), les librairies c'est la foire... Mais ça plait parce que ça permet d'avoir un seul langage pour le back et le front. L'avenir (à court terme) est dans le web. Je vois plus de perspectives pour JavaScript que pour Go malheureusement.

J'essaierai Rust à l'occasion. Ca semble complexe mais ça mérite de se creuser les méninges au moins pour pas finir idiot merci beaucoup

nam1962 · Le 01/03/2018, à 10:22

...de ce que je comprend, Go est utilisé sur les projets Blockchain.
(cela dit, Rust aussi : https://github.com/paritytech/parity )

shoot76 · Le 01/03/2018, à 10:29

ça n'a rien d'étonnant. La blockchain fait partie de ces projets qui nécessitent beaucoup de ressources et de disponibilité vu le traffic mondial et les besoins en ressource pour assurer ce traffic. Go présente l'avantage d'être concurrent nativement et léger en mémoire. Tu optimises donc ainsi les traitements CPU et libère la RAM pour autre chose. Ce choix me parait logique dans cette problématique

moths-art · Le 01/03/2018, à 13:38

Pour Rust, y'a une lib qui permet d'utiliser le principe des go routine : https://github.com/Xudong-Huang/may
Go est également un très bon langage : dommage que ça utilise un GC (ça lui donne un champ plus restreint que Rust) et que l'aspect générique manque pour des gros projets. Mais je me trompe sans doute, j'ai pas retesté depuis au moins 2 ans.
Pour ce qui est de NodeJS : je pense vraiment que Javascript connait actuellement son heure de gloire et que le souflet va retomber avec l'arrrivé à maturité de WebAssembly.
Microsoft a l'air d'avoir mis pas mal de bille la dedans et un framework clé en main en C# permettant de faire le code client et serveur est pas loin de poindre.
En Rust, y'a aussi cette volonté avec le projet https://github.com/DenisKolodin/yew
Une fois que ce sera mature, Javascript va décliner, inévitablement.
Pour s'imaginer : il sera possible de porter des libs entières (en C, C++) dans cette technos et par conséquent profiter de perfs presques natives.

shoot76 · Le 01/03/2018, à 14:46

moths-art a écrit :

[...]Microsoft a l'air d'avoir mis pas mal de bille la dedans et un framework clé en main en C# permettant de faire le code client et serveur est pas loin de poindre.

Source? Je suis intéressé d'y jeter un œil.

moths-art a écrit :

Une fois que ce sera mature, Javascript va décliner, inévitablement.

Je l'espère. NodeJS est parti en sucette quand ils ont commencé à exploser le nombre de librairies. La dernière fois que je l'ai utilisé, sans mentir, j'ai téléchargé une dépendance, j'ai commencé à lire la doc, tuto etc... j'ai commencé à coder. Et quand j'avais un truc fonctionnel, j'ai constaté que la lib n'était plus maintenue et considérée "out of date". J'ai adoré (mais vraiment!) quand Angular est sorti. J'ai cru que ça révolutionnerai le web. J'en ai fait à toutes les sauces! Et là, Google a sorti Angular2, un remake complet. Rien à voir. Tout à réapprendre. Puis angular 4 et 5 qui apportent leurs changements respectifs et leurs incompatibilités avec le code précédent. Même les grosses librairies gérées par Google font n'importe quoi. Alors ok, j'admets, le web change à une vitesse incroyable. Le JavaScript permet de faire beaucoup, beaucoup de choses! De l'appli de bureau avec Electron jusqu'à l'appli mobile avec ReactNative en passant par le web avec Node/Angular/React/Vue... Bref, y'a de quoi faire à peu prêt tout ce qu'on veut dans un seul langage. Mais à côté de ça, c'est la jungle! Faut être à l'affut de la moindre modif. Faut faire extrêmement attention à son code car c'est pas vraiment "maintenable" si on commence à faire des modifs à l'arrache. Bref, c'est très permissif et quand on veut faire les choses proprement, faut s'astreindre à une rigueur sans failles.

Je pense que tu as raison. Du moins, je l'espère sincèrement Le JavaScript c'est la porte d'entrée des Hackeurs sur la plupart des site web... si on pouvait arrêter de l'utiliser, ça serait pas mal. Surtout que, dans le fond, ça sert à rien d'autre qu'à faire des trucs "jolis". Fonctionnellement parlant, on pourrait s'en passer ^^

moths-art · Le 01/03/2018, à 15:18

Pour le lien : t'as déjà ça https://www.developpez.com/actu/188264/ … l-API-Web/ .Je suis pas trop branché Microsoft mais je commence à en entendre parler au taf.
Ce qui m'énerve le plus avec le JS c'est la duplication de code : j'en suis venu à sérailiser mes objets côté serveur pour en faire des objets javascript et générer des fichiers pour conserver la même hierarchie. C'est bien souvent trop lourd pour ce que ça doit réellement faire mais au moins j'ai plus de régression merdique parce que j'ai changé une virgule.
Faire de l'appli de bureau en JS c'est pour les hérétiques : pour du prototypage, des hackathons ou du one shot : ok... pour de l'appli durable, on passe son tour.
En ce moment, j'utilise pas mal Vue.js avec une stack webpack aux oignons. Ca évite quand même pas mal de piège une fois en place mais qu'est-ce que ça m'a pris comme énergie à configurer !

shoot76 · Le 01/03/2018, à 15:35

En fait, WebAssembly ne vise pas à remplacer le JS mais à ajouter d'autres langages au web. Je pense que Microsoft suit justement cette tendance du "tout web" en cherchant à y intégrer du code pour y éxecuter des applications, des jeux, de la VR... et tout ce qu'on va imaginer et créer d'ici là. Mais le but n'a pas l'air d'être l'éradication du JS.

Ah mais j'ai pas dis le contraire! Tu peux faire des trucs propres en JS. T'as les excellents precepts de John Papa d'ailleurs à ce sujet qui permettent d'uniformiser un peu et d'avoir une pseudo cohérence entre les gens qui les suivent. Moi même j'ai codé un projet en TypeScript et j'en étais fort content (pour une fois, je dois reconnaitre des qualités à Microsoft sur TypeScript!). C'est compilé en JS, c'est typé, c'est Objet, vraiment c'était cool. Par contre voilà, t'as tout dit, ça prend juste quinze an à configurer! D'un côté, tu prends n'importe quel langage et tu fais ton boulot en 10/15minutes chrono. De l'autre, tu passes 10minutes à télécharger les 15000 librairies et dépendances de npm pour ton projet, tu configures un webpack à base de copier/coller sur stackoverflow parce que la syntaxe est juste incompréhensible. Et là tu peux commencer à coder. Mais bon, ça fait classe dans un café hipster de dire que t'as codé en JS. Quoique, maintenant on va finir par retourner à l'assembleur avec ces fameux barbus qui poussent le vice à l'extrême ^^

Des applis en JS y'en a pas mal qui tournent bien. Dont une que j'utilise perso tous les jours : Atom Bon, c'est lourd... mais c'est gratuit Sublime à côté j'étais obligé d'aller chercher des clés sur internet... c'est pas très moral (ni légal).

nam1962 · Le 01/03/2018, à 16:10

Ce fil est passionnant, merci aux experts !

moths-art · Le 02/03/2018, à 11:03

shoot76 a écrit :

En fait, WebAssembly ne vise pas à remplacer le JS mais à ajouter d'autres langages au web.

Oui, tout à fait.
Et c'est justement là tout l'intérêt : on peut très bien faire cohabiter du Js et du webassembly pour diverses raisons :
- convertir une appli en webassembly progressivement sans tout casser ou tout recommencer
- conserver du js pour les zones ou le framework webassembly ne propose pas encore d'équivalent
- identifier les goulots d'étranglement et convertir uniquement les parties en webassembly pour accroire les perfs

En revanche, sur des projets neufs, j'aurais tendance à dire que dans un avenir proche, webassembly pourra se suffire à lui-même et beaucoup de projets/boites y trouverons leur compte.

Difficile de prévoir ce que ça va engendrer : est-ce que ça va encore plus segmenter le marché ou non ?

Avis perso : dans ma boite, on préfère embaucher des devs peu expérimenté (et par conséquent pas cher).
Vu que j'ai été désigné pour les former, je peux dire de source sur que : former sur 1 langage serveur et 1 langage client ça fait perdre beaucoup de temps inutillement.
Javascript s'apprend très facilement et il est aisé de produire rapidement mais être expert un investissement considérable.
Ca nécessite plus de review de code, de maintenance, de débuggage et les devs mettent beaucoup plus de temps à être réellement autonome.

shoot76 · Le 02/03/2018, à 11:19

moths-art a écrit :

shoot76 a écrit :
En fait, WebAssembly ne vise pas à remplacer le JS mais à ajouter d'autres langages au web.
Oui, tout à fait.
Et c'est justement là tout l'intérêt : on peut très bien faire cohabiter du Js et du webassembly pour diverses raisons :
- convertir une appli en webassembly progressivement sans tout casser ou tout recommencer
- conserver du js pour les zones ou le framework webassembly ne propose pas encore d'équivalent
- identifier les goulots d'étranglement et convertir uniquement les parties en webassembly pour accroire les perfs
En revanche, sur des projets neufs, j'aurais tendance à dire que dans un avenir proche, webassembly pourra se suffire à lui-même et beaucoup de projets/boites y trouverons leur compte.
Difficile de prévoir ce que ça va engendrer : est-ce que ça va encore plus segmenter le marché ou non ?
Avis perso : dans ma boite, on préfère embaucher des devs peu expérimenté (et par conséquent pas cher).
Vu que j'ai été désigné pour les former, je peux dire de source sur que : former sur 1 langage serveur et 1 langage client ça fait perdre beaucoup de temps inutillement.
Javascript s'apprend très facilement et il est aisé de produire rapidement mais être expert un investissement considérable.
Ca nécessite plus de review de code, de maintenance, de débuggage et les devs mettent beaucoup plus de temps à être réellement autonome.

C'est un peu la problématique des boîtes actuellement. C'était le fer de lance de NodeJS d'ailleurs. Comme quoi un dev front pouvait maintenant faire du back. Ca permettait, en théorie, de faire des économies de main d’œuvre. Maintenant la réalité est toute autre. Quand tu vois bosser des devs front, ils te font un truc qui marche... faut pas être très regardant sur la qualité du code, disons. Alors mets moi un dev front sur du back, et je t'assure que pour 90% d'entre eux ça va produire un code digne des plus belles bouses. Sans compter les problématiques d'architecture dont ils sont totalement étrangers.

Chacun son métier. Un dev front fait du front, un dev back, le back. Des langages différents? A la limite, on s'en fout. Autant être expert dans un langage et faire un truc propre que de faire des trucs à moitié. Enfin c'est ma façon de penser. Mais les boîtes (dont la tienne visiblement) qui préfèrent embaucher des jeunes m'exaspèrent. Y'en a une pas loin de chez moi qui fait que ça... ça ratisse dans les écoles, dans les facs... Ils tirent les salaires vers le bas au possible. Des étudiants en sortie de master ou de diplôme d'ingé qui se retrouvent avec un salaire à peine plus élevé qu'un SMIC. Difficile à croire. Et après cette boîte les vend comme des "experts" alors qu'ils n'ont aucune formation particulière hormis celle de leur école. Quand ils sont venus me chercher, j'ai ris en voyant leur proposition et je lui ai demandé si c'était une blague. Le mec s'est mis à m'insulter de tous les noms d'oiseaux et comme il a le bras long, m'a fait une belle promo auprès des autres boîtes. Histoire de bien me pourrir. J'ai fini par trouver, avec un salaire et des conditions morales décentes. Mais je garde de ce genre d'entreprise une très mauvaise image.

J'espère vivement que ta boîte recrute des jeunes pour des raisons morales et non pas pour des raisons purement économiques.

moths-art · Le 02/03/2018, à 13:47

Bon, je change de boite d'ici peu (notamment raisons évoqués). Je dirais qu'un dev back fera du front sans problème : l'inverse est souvent faux. (même si les mentalités changent et que les process de dev front commence de plus en plus ressembler au back)
Ma boite ne prend plus que des dev full stack avec un salaire à peine au dessus du smic. (sans compter que y'a des connaissances métier très spécifique : domaine médical)
Ils souhaiteraient embaucher des personnes expérimentés mais ne trouve pas (allez savoir pourquoi)
Y'a aucune morale la dedans : que l'intérêt du profit immédiat.

Je suis d'avis de ne pas classer les gens uniquement dans le front ou le back : sinon, ça donne vraiment des fonctionnement scabreux.
Néanmoins, nommer des personnes expertes dans un domaine afin qu'elles perfectionne cet aspect me semble primordiale.

Ex : le gars qui a plus de facilité en SQL sera orienté vers le status de DBA.
Le gars qui touche en CSS sera référent et guidera l'équipe sur les bonnes pratiques.
etc.

Le soucis des boites qui veulent des devs bons en tout c'est qu'elles se retrouvent au bout du compte avec des softs médiocres.
Pour pas mal de boite, ça leur pose pas de soucis, ils renforcent le pouvoir de vente, le service de formation et d'assistance (qui sont souvent bien plus lamentables que le code) et ça passe comme une lettre à la poste.
La plupart des responsables financiers voient le dev déjà comme quelque chose de linéaire : on rajoute 10 fonctionnalités en tant de temps puis 10 supllémentaires et le cout de maintenance est identique (voir proportionnel) alors que souvent l'explostion combinatoire nécessite plus d'investissement à tout maintenir, refactoriser, documenter (car on peut plus connaitre le code par coeur), changer de paradigme, rajouter des tests unitaires etc.
Résultat, les délais sont plus dur à respecter donc on accrois les effectifs (juste ce qu'il faut).
Une fois en place, on durci les conditions (on presse les employés comme des citrons) et augmenté le prix de nos applis.
Quand on arrive au point fatidique ou ça ne marche plus et que la poule aux oeufs d'or c'est arrêté, on a déjà la moitié qui est parti de son plein gré et le reste en licenciement éco.
On a prévu le coup et on arrête cette filiale.
C'est affligant mais une des réalités.

shoot76 · Le 02/03/2018, à 14:26

Bon au moins, on est d'accord.

Après on vient présenter le développement informatique comme une alternative sérieuse au chômage. Une reconversion aisée et de l'emploi facile. C'est pas faux... faire du dev ça demande une certaine logique et habitude, mais y'a rien d'insurmontable pour un esprit ouvert et curieux. L'emploi, c'est sûr, ça recrute. Par contre, faut pas regarder les salaires quoi...

Bref c'est pas le sujet... Je sais pas où tu pars mais ils ont certainement la chance de décrocher un bon dev. Ça devient rare. Comme tu dis, on préfère faire de la merde et vendre de la maintenance, que faire un truc propre et vendre du service. Après tout, tant qu'il y a des clients pour acheter.

nam1962 · Le 02/03/2018, à 14:31

Là on est sur un autre sujet, mais il est vrai dans tous les métiers que ceux qui payent les talents mènent la danse (et les autres n'ont que les médiocres ou presque).

minizebr95 · Le 07/03/2018, à 17:31

Naziel a écrit :

Les M&M's jaune

Les rouges sont bien meilleurs, plus orientés cachuètes !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 28/02/2018, à 14:54

Re : Participer à un projet

#27 Le 28/02/2018, à 15:08

Re : Participer à un projet

#28 Le 28/02/2018, à 21:00

Re : Participer à un projet

#29 Le 28/02/2018, à 21:13

Re : Participer à un projet

#30 Le 28/02/2018, à 21:17

Re : Participer à un projet

#31 Le 28/02/2018, à 21:32

Re : Participer à un projet

#32 Le 28/02/2018, à 21:43

Re : Participer à un projet

#33 Le 28/02/2018, à 22:33

Re : Participer à un projet

#34 Le 01/03/2018, à 10:09

Re : Participer à un projet

#35 Le 01/03/2018, à 10:22

Re : Participer à un projet

#36 Le 01/03/2018, à 10:29

Re : Participer à un projet

#37 Le 01/03/2018, à 13:38

Re : Participer à un projet

#38 Le 01/03/2018, à 14:46

Re : Participer à un projet

#39 Le 01/03/2018, à 15:18

Re : Participer à un projet

#40 Le 01/03/2018, à 15:35

Re : Participer à un projet

#41 Le 01/03/2018, à 16:10

Re : Participer à un projet

#42 Le 02/03/2018, à 11:03

Re : Participer à un projet

#43 Le 02/03/2018, à 11:19

Re : Participer à un projet

#44 Le 02/03/2018, à 13:47

Re : Participer à un projet

#45 Le 02/03/2018, à 14:26

Re : Participer à un projet

#46 Le 02/03/2018, à 14:31

Re : Participer à un projet

#47 Le 07/03/2018, à 17:31

Re : Participer à un projet

Pied de page des forums