Concernant les appli de gestion, je peux te demander de jetter un coup sur le code source de l'ERP Compiere, il est disponible sur sourceforge. une soixantaine de personnes y travailles dessusEnvoyé par zecreator
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Concernant les appli de gestion, je peux te demander de jetter un coup sur le code source de l'ERP Compiere, il est disponible sur sourceforge. une soixantaine de personnes y travailles dessus
Donc on est d'accord pour dire que les formalismes sont indispensables dans certains secteurs d'activités mettant en place de gros projets de gestion, mais que cela peut être optionnel dans d'autres secteurs plus ludiques, comme le jeu vidéo, les outils multimedia...Eh bien... Je vois les applis télécom (pas toutes, mais si tu regardes un peu les standards 3GPP et autres protocoles télécom, tu te rendras compte que tout avoir dans la tête, même si on est "créatif", c'est impossible), des projets de refonte de SI dans les banques, des applis médicales, certains projets de la défense, des projets aéronautique (tu te vois coder tout seul tout le système informatique d'un Airbus ???)...
Et je suppose que tout le monde a quelques exemples personnels à donner.
Les formalismes de développement font apparaitrent surtout des projets utilisant des moyens financiers et/ou humains étendus.
Comme je suis curieux, est-ce que ceux qui développent dans le domaine professionnels élaborent également des projets persos ? Et utilisent t-ils ses formalismes pour eux ?
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Oui. Moins ces dernières années, mais je compte m'y remettre.
Je n'ai que rarement fait des docs, parce qu'en général mes projets étaient vraiment minuscules, et qu'un fichier readme suffisait à tout expliquer.
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
Pour repondre au sujet initiale pour moi c'est oui , je fait de la programmation spontanee , mais sur des mini-projet tout aussi spontanee ( rarement plus de 5k lignes de codes mais presueq tous plus de 1k ), tout en sachant que bien sur moi je suis pas un devellopeur mais je suis admin .
Qu'est-ce que j'entend par projet spontanee :: quand on se rend compte qu'il manque un utilitaire hop faut un machin pour dans trois jour parce que le client en a tout de suite besoin et qu'on veut pas payer 10 000 Euros pour 3h d'utilisation d'un logiciel , ou alors rajouter une fonctionnailte a un logiciel ).
Soit moi sa n'a rien a voir avec vos projet de 4G de lignes de codes mais ca reste de la programmation.
meme si je me souviens que fait le soft au bout d'un mois le code est commenter et permets a celui/celle qui passe par la de continuer ou de rectifier ce que j'ai fait
voila c'etait mon avis
J'arrive peut-être un peu tard (ce fil est référencé par la newsletter d'octobre, félicitations !)
Peut-être que l'avis d'un étudiant "contre" la programmation spontanée (je n'ai pas tout lu, peut-être ne suis-je pas le seul étudiant dans ce cas — je l'espère ! —) compte, puisque justement je n'ai pas l'expérience des "vieux" sur des projets de grande ampleur.
Je suis en école d'ingénieurs, en informatique, après un DUT Informatique (pour placer les choses).
D'abord, quel est le langage utilisé ? Nous avons eu la joie d'apprendre, l'année dernière, le Lisp. Qui veut faire de la programmation spontanée oubliera ce langage. Et ce n'est pas le seul à être dur à lire (quel doux euphémisme !). Ensuite, d'autres langages plus communs permettent, effectivement, de faire plus facilement du bricolage. Et encore, ils ne sont pas très nombreux, même si au premier abord on peut s'y tromper. C'est vrai qu'on peut "s'amuser" sur C++ (j'en connais qui ont commencé à programmer là-dessus, les pauvres), mais de là à faire quelque chose de professionnel et d'efficace, il y a un gouffre sans fond (infranchissable, garanti).
Ensuite, comme d'autres l'ont dit, si le programme est repris par quelqu'un d'autre, il faut qu'il soit compréhensible. Je vais me baser sur ma propre expérience : à l'IUT, on m'a demandé de reprendre un logiciel existant en Delphi/Interbase, qui présentait "quelques" bugs (qui empêchaient néanmoins l'utilisation initialement prévue). Sur 1500 lignes de code (une bagatelle, assurément), il n'y avait que 6 lignes de commentaires. On peut se dire que 1500 lignes, il n'y a pas besoin d'être sorcier pour lire ça. Ben faut croire que si. Je n'ai gardé que l'interface. Et pourtant, quand un camarade avait un problème, il me demandait où était le bug. Ca ne ratait jamais (ou presque), je trouvait le bug, aussi sale fut le code. Je n'essaie pas de m'envoyer des roses, mais comme quoi, même en prétendant savoir lire le code des autres "facilement", on trouve toujours plus fort que soi.
Par ailleurs, l'évolution du produit est essentielle. Dans les années 70, des programmeurs improvisés ont écrit en Cobol des logiciels de gestion pour des banques. La plupart n'avaient pas de formation professionnelle et ne se souciaient pas de fournir une documentation complète de leur produit. A l'approche de l'an 2000, beaucoup d'établissements bancaires ont payé une fortune pour mettre à jour leur système. Alors qu'avec une documentation (et sous réserve que le code soit bien structuré), on aurait presque pu continuer en Cobol, en mettant juste quelques détails à jour. Ensuite, il est vrai, pour coller au domaine précédemment cité, que beaucoup de jeux vidéos meurent très jeunes (les pauvres) et n'ont pas le temps de connaître le poids des années.
Egalement, le travail en équipe. Nous avons récemment produit un compilateur en TP (de compilation, comme c'est étonnant !) dans le cadre de notre formation. Quelqu'un aurait pu s'en charger tout seul, éventuellement, mais l'objectif était aussi de travailler dans une équipe de 8 (ce qui n'est pas grand chose à côté de ce qui nous attend plus tard). Si nous n'avions pas utilisé une formalisation UML pour pouvoir tout faire fonctionner ensemble, on n'y serait jamais arrivés. D'ailleurs dans l'équipe voisine, ils ont pris les décisions sans rien noter, et chacun a fait en pensant qu'il respectait les consignes. Résultat : pour peu ils y seraient encore (ça fait 6 mois de ça).
Enfin, essayons de faire la comparaison avec les autres secteurs de production. Est-ce qu'on a déjà vu des ingénieurs dans l'automobile construire une voiture, en corrigeant et en testant, avant de dire : "OK, vous pouvez en faire d'autres comme celle-là", sans faire une étude structurée, des modélisations 3D, des tests en simulations, ... A-t-on déjà rencontré des ingénieurs en aéronautique assembler des bouts de métal avant de réfléchir en projet et en commissions aux différents aspects de l'avion ? Ou encore, le viaduc de Millau a-t-il été construit au "feeling" ? Pourquoi l'informatique ne serait pas elle aussi rigoureuse ?
J'ai sans doute répété ce que beaucoup d'autres ont dit précédemment, 20 pages ça faisait beaucoup à lire d'un coup.
En bonus, un petit cadeau aux "programmeurs spontanés". L'énoncé du problème est le suivant : un voyageur de commerce doit pour son travail traverser un ensemble de N villes. Il doit toutes les traverser une fois et une seule. Le chemin choisi doit le ramener à son point de départ. Le problème est de trouver le ou les chemins les plus courts qui vérifient ces propriétés.
(ceux qui connaissent la solution, ne la donnez pas)
On s'amuse de rien en vieillissant, on vieillit quand on ne s'amuse plus.
Yo,
Je suis actuellement dans une vraie équipe de développeurs, c'est que du bonheur! Par le passé, j'ai travaillé dans une boite où le mot d'ordre était "On est là pour gagner de l'argent." Résultat, on vendait des softs, et il fallait se dépêcher ensuite pour les coder. On y affectait un gars qui se débrouillait tout seul en programmation spontanée pour arriver à un résultat vendable, souvent sans avoir de vraie connaissance "métier" (compta, en l'occurence), et les stagiaires, c'était bien, ça coutait pas cher. Bref, un louable excercice de style, impeccable commercialement... C'était vendu avec le contrat de maintenance. Résultat des courses, plus de hotlineurs que de développeurs, 2 arrêts de travail dans l'encadrement pour dépression grave au passage à l'euro, et la boite quasiment sur les genoux. 1800 programmes avec chacun une gestion différente de l'euro, souvent écrite plusieurs fois dans le soft, la version informatique de la roulette russe... J'ai passé des heures a essayer de comprendre des sources sans commentaires et sans structure. Ca pousse vraiment à coder correctement. La meilleure de toute: Le dépannage en urgence chez le client, à se faire traiter de tous les nom pour un soft qu'on n'a pas écrit... La semaine suivante, le patch qu'on vient de faire est écrasé par une mise à jour automatique... Tout le monde dans son expérience scolaire devrait être confronté à ce genre de truc, ça évite par la suite de coder comme un boulet.
Je n'ai rien contre les petits génies, ils sont là pour avoir des idée, mais il faut qu'ils se contentent de ça, c'est absolument incompatible avec une programmation professionnelle. Parce que j'en ai vu une paire commencer plein de choses pour les laisser finir par les autres, c'est ce qu'il peut arriver de pire mais c'est très fréquent. On est bon pour réécrire, et c'est très dur à justifer. Perso, je ne suis pas capable de dire à un chef de projet "c'est n'importe quoi, ton truc", même si c'est vrai.
A+
Pfeuh
@pfeuh: un gros +1 !
Pour un peu, je croirais que t'es dans la même boîte que moi !
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
C'est une évidence...
Encore heureux, ils ne t'ont rien fait. Je pense que ceux qui pratiquent régulièrement la programmation spontanée, ne sont pas forcément des génies (que l'on ne voit pas là une insulte de ma part), mais on sûrement la capacité d'analyser rapidement un besoin et de concevoir une solution. Je pense aussi, je prend mon cas, que ceux sont des personnes qui aiment expérimenter des nouvelles techniques et qui peuvent passer beaucoup de temps sur un bout de code. Et pour finir, ceux sont des personnes qui ne manquent pas de resources et peuvent utiliser une large palette d'outils de développement différents.pfeuh a dit : Je n'ai rien contre les petits génies, ils sont là pour avoir des idée, mais il faut qu'ils se contentent de ça, c'est absolument incompatible avec une programmation professionnelle. Parce que j'en ai vu une paire commencer plein de choses pour les laisser finir par les autres, c'est ce qu'il peut arriver de pire mais c'est très fréquent. On est bon pour réécrire, et c'est très dur à justifer. Perso, je ne suis pas capable de dire à un chef de projet "c'est n'importe quoi, ton truc", même si c'est vrai.
Maintenant, utiliser ce type de programmation lorsque tu as des clients qui paient des milliers €, c'est un peu sucidaire. C'est malheureusement très tendance comme pratique. Comme je le disais dans un ancien POST, les SSII sont tenues par des commerciaux qui sont là pour vendre, et qui ne se soucient pas des contraintes techniques. Perso, les SSII je les fuis comme la peste, ça tue l'épanouissement des développeurs dans leur métier.pfeuh a dit : Par le passé, j'ai travaillé dans une boite où le mot d'ordre était "On est là pour gagner de l'argent." Résultat, on vendait des softs, et il fallait se dépêcher ensuite pour les coder. On y affectait un gars qui se débrouillait tout seul en programmation spontanée pour arriver à un résultat vendable, souvent sans avoir de vraie connaissance "métier" (compta, en l'occurence), et les stagiaires, c'était bien, ça coutait pas cher.
(J'ai jamais pû sentir les blaireaux en costard-cravate, avec un gros salaire, qui te considère comme un simple outil et qui viennent te dire comment tu dois bosser, alors qu'ils n'y connaissent rien...)
Tu t'apercevras vite que beaucoup de développeurs aiment à garder secret leur codes sources (ce qui me semble légitime personnellement), et ne te faciliteront pas le travail de récupération. Y a aussi de l'orgueil chez les développeurs, et la volonté de garder l'exclu de son code...Alain Dionne a dit : Ensuite, comme d'autres l'ont dit, si le programme est repris par quelqu'un d'autre, il faut qu'il soit compréhensible.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
@pfeuh: un gros +1 !
Pour un peu, je croirais que t'es dans la même boîte que moi !
Pareil dans ma boite!
il y avait un genie qui nous a quitte, son code etait un peu brouillon, complexe, mais remarquablement intelligent.
aujourd'hui son nouveau remplacant en souffre, il a herite d'un source complexe et non documente
depuis, je me mets a documenter, il est clair que ca rendra service.
je crois que le centre de ce debat, c'est bien l'orgueil...Tu t'apercevras vite que beaucoup de développeurs aiment à garder secret leur codes sources (ce qui me semble légitime personnellement), et ne te faciliteront pas le travail de récupération. Y a aussi de l'orgueil chez les développeurs, et la volonté de garder l'exclu de son code...
vouloir garder son source secret, c'est vouloir trahir la boite qui t'emploie.
Du coup si demain tu te fais écraser par une voiture, ton successeur risque de te maudire...
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
Il y a peut-être un milieu entre la programmtion spontanée et la progrmmation "réfléchie.
Je me suis remis à la programmation après 15 ans d'arrêt. Si les méthodes d'étude ne sont plus les mêmes, c'est parce que les langages ont évolué. J'ai donc choisi d'y revenir par le PHP qui me laissait une grande liberté.
Mais maintenant, je travaille avec des classes et je commence à les étendre. Ce n'est pas pour ça que je modélise mon application de façon formelle. Je commence par "visualiser" les écrans dont j'ai besoin, puis les échanges nécessaires au fonctionnement et je déduis ainsi la structure des données que je pense optimale. Je fais cela en pensant toujours que mon application va évoluer, donc je sépare au maximum (parfois à l'extrème) les données "pures" des index.
De plus, comme c'est de l'Open Source, je commente mon code le plus possible.
La programmation spontanée telle qu'elle est définie au début de ce fil n'est envisageable que pour un prototype. Il faut ensuite reprendre le code et le structurer. Mais ça permet d'avoir une idée claire de ce que l'on veut faire.
Bien sûr je suis loin des milliers de lignes de certains et je comprends que ce genre de situation nécessite des méthodes rigoureuses. Par contre, j'estime quelles "brident" l'imaginaire du développeur qui ne fait plus que chercher des solutions en appliquant des règles au lieu de se fier à son inspiration.
Et c'est là quelque chose que j'ai constaté à de nombreuses reprises, avec des développeurs qui savent bien appliquer les méthodes modernes mais, à cause de leur manque de "projection", sont incapable de corriger un bug.
Pour conclure, l'usage de la programmation spontanée ne doit être emplyée qu'au début d'un développement. Elle permet au développeur de se poser certaines questions et de ne pas se retrancher derrière une quelconque méthode d'étude. Il faut ensuite le structurer, ne serait-ce que pour l'optimiser. Car si tout le projet est géré de la même façon, on va droit dans le mur...
Pas trop d'accord. Les formalismes ne sont utilisées que pour décrire, pas pour chercher des solutions. Tu réfléchis, tu imagines une solution au problème, et tu la décris à l'aide des différents formalismes utiles.
C'est sûr que les méthodes ne sont pas là pour résoudre le problème posé par le cahier des charges, mais pour encadrer le projet. S'il suffisait d'appliquer une méthode pour obtenir un programme, ça fait longtemps que les ordinateurs s'auto-programmeraient !
Là, je suis plutôt d'accord avec toi. Pour faire rapidement un prototype, inutile de décrire pendant des jours ce qu'on va faire.
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
Re salut
J'ai l'impression que l'on fait un peu de mélange. Le thème parle de programmation (pas de conception, pas d'analyse) spontanée. Donc je me situe à la phase de programmation une fois que j'ai compris ce que doit programmer (je peux l'avoir compris en lisant un schéma UML, ou un cahier de charge). Pendant cette phase, on doit coder en ayant à l'esprit qu'on doit se faire comprendre aussi bien par un lecteur humain que par la machine et on peut y parvenir avec un minimum de commentaire/documentation. Car j'ai déjà vu à plusieurs reprises des commentaires, et des documentation ambigus. Si bien que c'est en lisant le code lui même que je comprend ce que le redacteur voulait dire dans ces commentaires/documentations.
Et pour la maintenance d'un code source, si on programme "proprement" avec des noms de variables,methodes etc. non ambigus, avec une structure simple, un bon système de loging, l'utilisation en plus d'un IDE riche est largement suffisant pour permettre une bonne maintenance du code. (franchement je ne vois même pas l'aide que pourrait m'apporter en plus des docs externes ou des diagrammes UML)
Je vais jouer mon gars de gauche mais, vu le nombre de compétences demandées à un développeur et le refus par les employeurs de revaloriser les salaires, c'est de bonne guerre.vouloir garder son source secret, c'est vouloir trahir la boite qui t'emploie.
N'oublions-pas que les développeurs, tout comme n'importe quel métier de création peuvent prétendrent à un droit intellectuel sur leurs productions, ce que les entreprises ont tendance à oublier.
Tout à fait d'accord sur le fait que les méthodes d'aujourd'hui brident trop le développeur et sa créativité. On fini par devenir des robots, comme à la grande époque d'IBM, mais en plus coloré.Bien sûr je suis loin des milliers de lignes de certains et je comprends que ce genre de situation nécessite des méthodes rigoureuses. Par contre, j'estime quelles "brident" l'imaginaire du développeur qui ne fait plus que chercher des solutions en appliquant des règles au lieu de se fier à son inspiration.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Bonjour,
Je pense que l'on peut faire une analogie avec la littérature
Lorsqu'on écrit de petits textes ou que l'on poste un message
nous avons rarement besoin de faire préalablement un "brouillon".
Maintenant lorsqu'il s'agit d'écrire un livre c'est une autre paire
de manches...
Dans ces deux cas, l'origine est la même. L'information est traîté
par le cerveau puis en fonction de la taille du travail on utilise ou
non un "brouillon".
En ce qui concerne le domaine scientifique, dont l'informatique,
nous sommes tenu à une démarche formelle,
que ce soit avec un "brouillon papier" ou un "brouillon mental".
Ces deux brouillons permettent d'arriver au résultat. La différence
c'est la capacité du "brouillon mental". Personnellement, je m'efforce
toujours de modéliser sur papier car cela me permet de revenir dessus
bien longtemps après et cela me fait gagner du temps parcequ'il n'y a
plus besoin de redevoir réfléchir à nouveau sur les bases.
Pensez aux joueurs d'échec, ils réfléchissent à plusieurs coups
à l'avance. Mais la partie n'est pas nécessairement un programme car
cette partie ne sera pas forcément la même la fois suivante...
Quand à l'art et la science, le premier se base plus sur l'unicité
car il est rare de voir plusieurs oeuvre identiques si ce n'est des copies.
Tandis que le second devra toujours réagir de la même manière obéir
toujours aux mêmes lois, à la même logique comme le ferait la plupart des
programmes.
Pour ce qui est de transmettre l'information, c'est une autre question.
Cela relève plus de projet de groupe pour lequel celui-ci devra utiliser un
langage commun pour que l'ensemble puisse se comprendre sans ambiguïté.
C'est un débat très vaste mais enrichissant.
ps: pour ce message je n'ai pas utilisé de brouillon
Eh ben, quel débat !!!
Je sens comme une odeur de chaussettes cramées au début de la discussion. le type, 'DOLOOP', invité de passage de surcroit, a les chevilles qui enflent
Perso, je programme depuis plus de 10 ans dans différents langages (Delphi, VB, C++ principalement), et je n'ai que 2 mots à dire : CONNAISSANCE et PRATIQUE.
Dans toute discipline scientifique (et oui l'informatique en est une), les bases et la pratique régulière sont obligatoires et indissociables. Dans ce forum, il y a beaucoup de personnes qui l'ont bien compris et l'ont cité à juste titre. Merci d'avoir fermer le clapet de cet einstein.
Bon, il est vrai que la programmation spontanné est tout à fait logique avec la pratique. qui n'a jamais codé une routine en moins d'une heure sans dessiner le moindre UML, hein ? franchement.
Soyons honnetes, nous somme tous capable d'en faire autant.
D'un autre côté, et là je vais jeter un pavé dans la marre, l'utilisation excessive d'une modélisation peut provoquer ce que l'on pourrait appeler : la machine à gaz. Je sais, vous allez me dire : 'il est con celui là, c'est fait pour simplifier !!' . Oui je sais, mais dans bon nombre de cas, la modélisation apporte plus de contrainte qu'autre chose. La performance d'une programme ou d'une routine ne réside pas dans sa modélisation tip-top, mais dans son optimisation de codage.
Eh oui, je suis un adepte des optimisations extrèmes, et je déteste le java pour cette raison.... bref, cela pourrait être un autre débat.
je finirai là dessus : PERFORMANCE = OPTIMISATION / MODELISATION
trop de modélisation tue la modélisation
Salut
Rien ne t'empêche de passer indépendant. Comme ça tu pourras bosser comme tu veux !
Si les méthodes privaient vraiment le développeur de sa créativité, il n'y aurait plus besoin d'humain dans le cycle de développement.
Il suffirait de donner l'expression de besoins à un ordinateur, et en suivant une méthode, il pourrait générer le code !
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
La modélisation, c'est bien. En abuser, ça craint
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
Vaste débat
Au risque de reprendre certaines remarques déjà fournies au sein de ce débat, je suis en effet d'accord sur le fait que cela dépend de la taille de l'application et du nombre de personnes à travailler sur le projet. Pour un programme simple de quelques centaines de lignes, qq soit le langage, le développement peut être fait en programmation spontanée, ce que je fais régulièrement, avec un attachement tout particulier à commenter mes lignes de code (et là on s'y retrouve toujours plus tard...). Cette manière de programmer intuitive demande de la rigueur dans sa manière de penser le programme et quelques années (!) de métier et de connaissance mais elle a l'avantage de ne pas trop perdre de temps à une analyse pas toujours essentielle dans de pareils cas.
Or pour des projets plus ambitieux, type gestion commerciale ou autre que j'ai l'habitude de développer, ou pour des applications où plusieurs programmeurs doivent intervenir, cela me semble essentielle de préparer le projet en effectuant une analyse précise préalable, en définissant évidemment un cahier des charges, et au besoin des algorithmes détaillés, UML,...etc, non seulement pour soi-même et éviter ainsi de se perdre dans une programmation douteuse, mais également pour les autres intervenants, car chaque programmeur a sa manière de penser et de programmer...
Développeur indépendant depuis 13 ans et analyste-programmeur depuis 20, j'emploie donc les 2 méthodes, tout dépend du contexte comme je viens de le préciser ; mais il est vrai aussi que le temps est précieux pour tous, et qu'une analyse trop longue peut dissuader le Client d'accepter un projet. Ainsi avec le temps on acquiert une manière de travailler, non pas en baclant une partie du travail loin de là, mais en possèdant des automatismes de pensée et de programmation, mélant rigueur et savoir-faire, pour atteindre le but recherché : que l'application tourne parfaitement, avec un code optimisé, et le faire dans des délais raisonnables.
L'analogie à la littérature d'une précédente remarque (excuse moi je n'ai plus ton nom en tête) me parait tout à fait bien trouvée. Certains auteurs ont besoin de structurer un récit et passer du temps à tout planifier, alors que d'autres peuvent passer à l'écriture directement, laissant libre cours à leur inspiration. Et dans l'un et l'autre des cas, il y aura des bons et des mauvais romans...
Salut.
Sans vouloir, par ce message, défendre un partie ou l'autre:
Je pense que vous différenciez mal la DOCUMENTATION TECHNIQUE et l'ANALYSE DE PRÉ-DEV.
Une personne qui ne fait aucune analyse prédev, met son truc en prod, puis se barre de la compagnie, s'il à fait une documentation technique adéquate, il ne met en rien l'entreprise dans la merde.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager