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 :
Oui la critique n'est pas admise chez eux d'ailleurs developpez est déjà parti en procès avec eux il me semble....Envoyé par benwit
Tu peux nous en dire plus ?
On ne trouve pas de critique argumentée dans leur belle plaquette commerciale
C'est aussi une des raisons qui font que je n'interviens plus dans le forum associé ni ne travail avec ce produit à présent bien qu'il devance (à mon goût) les EDI traditionnelles puisque c'est un vrai EDI c'est un AGL(qui inclus un RAD bien entendu).
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
ok
Windev est l'outil RAD par excellence.
Mettre Windev entre les mains d'un glandeur, clickeur, pressé, jeunnot, "bleu-bite", débutant, bidouilleur, permet d'arriver au résultat souhaiter par l'entreprise (une belle application fonctionnelle qui fait ce qui était voulu) mais pas au même résultat qualitatif (sur le plan MAO).
En gros, dans ce cas là (avec un débutant qui utilise un RAD), le temps gagné avec un RAD lors de la conception est vite perdu en x4 lors du moindre débuggage/TMA où le développeur n'est plus là ou l'outil RAD n'est plus disponible ou à jour..etc. Charge au responsale info d'être rigoueux sur le maintien de son parc et du savoir dans l'entreprise!
La faute provient du chef de projet qui positionne un débutant sur un RAD et également au CDC qui ne vérifie pas le travaille qualitatif et fonctionnel de son subordonné.
Windev est hélas, l'outil RAD le plus critiqué (souvent par des linuxiens d'ailleurs) ou programmeur solitaire-bidouilleur.
Par contre,
Mettre windev dans les mains d'un vrai Ingénieur développeur, un architecte applicatif, bref quelqu'un qui visualise où il veut aller avant de cliquer et là Windev devient un Outil Magique !
Si la plupart des gens qui critiquent les RAD étaient aussi minutieux et réguliers dans leurs productions de code ce serait déjà ça. mais j'ai remarqué que la plupart des gens qui sont contre les RAD sont les mêmes personnes qui ne mettent jamais de commentaire dans le code, qui ne font jamais de doc, bref qui codent à 100Km/h sans regarder devant soi.
Windev est un excellent Outil, c'est le bonhomme derriere la souris qui l'utilise mal qu'il faut taper :-)
Dans un genre un peu similaire, j'ai remarqué sur des forums que Jbuilder de Borland est un peu la bête noire des pures codeurs Java....
J'ai l'impression que les codeurs "à la main" n'aiment pas les applicatifs qui font leur boulot mais en plus vite....
C'est le comble : l'informaticien qui n'aime pas les ordinateurs car il fait leur boulot à leur place !
C'est hélas le principe de l'évolution humaine : l'homme de la génération X n'apprécie guère la génération X+1 qui fait le même travaille que la génération X-1 en moins de temps, en moins de difficulté, en mieux..etc.
Je pense qu'il y a deux façons de valoriser le travail fait à partir d'un RAD.
La mauvaise : "super on a fait en 1h de clic ce qu'on aurait fait en 10 jours de code", aller on le facture 10j/h à 100€ de taf et vive les bénéfs pour nous!
La bonne : "Grâce au temps gagné avec le RAD, on va s'appliquer à une autre tâche qu'on n'aurait pas pu faire dans l'empressement et on va vendre notre ingénieurie plutôt que notre main d'oeuvre : facturation d'1 jour/h à 1000€.
J'ai pas vu la question posée plus haut, mais pour moi la différence entre un RAD et un framework est minime : un framework est un RAD sans GUI (front end).
Un vrai ingénieur développeur ne supportera pas d'avoir un pont ultra mince entre sa base de données et sa couche GUI. C'est ce qui nous a perdu nous ici.Mettre windev dans les mains d'un vrai Ingénieur développeur, un architecte applicatif, bref quelqu'un qui visualise où il veut aller avant de cliquer et là Windev devient un Outil Magique !
Pas plus que le niveau d'isolation maximum read-uncommited de hyperfile ne sera jugé suffisant pour une applic concurrentielle critique.
Nous avons été séduit par les possibilités de développement rapides de windev, toutefois lorsque l'application est devenu complexe et la base de donnée importante, nous avons malheureusement été obligé d'admettre que nous nous étions trompés complètement en choisissant cet outil pourtant séduisant à bien des égards...
Vous confondez les termes il y a une différence entre un framework, un edi ou un agl ce n'est pas du tout le même concept.
Windev ce n'est pas un RAD c'est un AGL certe qui inclus un RAD mais ce n'est qu'un petit morceau d'un AGL un RAD
Aujourd'hui en terme de AGL ce qu'il y a de plus abordable pour les développeurs et qui ne nécessite pas 100mois de formation c'est windev en plus c'est franco-français. Son impopularité chez les développeurs vient probablement plus du langage windev le w-langage.
_skip> il est possible de mettre une base oracle derrière ou autre chose c'est un choix auquel vous ne pouvez n'en vouloir qu'à vous. Aussi ce n'est pas de la faute de l'outil pour les accès concurrents critique c'est une question de conception que vous n'avez pas maîtrisée avec l'outil. Idem pour la couche GUI/DataBase c'est une question de conception on peut très bien découpler complètement ces couches.
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Puisque tu le dis
c'est simplement mon opinion/diagnostic cela ne veut pas dire que j'ai tout raison et toi tout tord c'est un débat, c'est le fait de rejeter la faute sur un outil qui est un peu grotesque à mon goût.
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Je doute que ça t'intéresse mais je pourrai ressortir tout ça, argumenter clairement le pourquoi de mon opinion mais ça n'a rien à voir avec ce débat.
Sache juste à mon égard que je me remets en question longtemps avant de m'en prendre aux outils.
framework : ensemble de fonctions/objets englobant une couche d'abstraction d'accès au données et une certaine (minimum quand-même) génération de présentation (via template).
EDI = outil graphique destiné à moins utiliser le clavier et valoriser la souris ainsi qu'une bibliothèque de fonctions/objet/syntaxe/snippets
AGL = EDI + notion de modèle relationnel/UML des données
RAD = framework + agl + edi + production d'aspect graphique automatisé (en tout cas plus 'userfriendly' que le fait un framework)
c'est ma vision, je conçois tout à fait que personne ne la partage. L'expérience est formatrice de chacun, pas de tout le monde.
Je ne suis pas vraiment d'accord avec tes définitions.
Je dirais plutôt :
Framework = Cadre de travail. Un framework est un ensemble de composants/librairies qui va servir à structurer l'application et les développements. Toute application fait nécessairement appel à un framework, sous une forme ou une autre. Après, il existe des frameworks très génériques (par exemple le framework .Net) et des frameworks spécialisés (ORM, gestion des traces/Logs, gestionnaires de fenêtres...). Ils fournissent un ensemble d'outils pour réaliser un service donné.
EDI = Environnement de développement intégré. On peut y mettre pratiquement tout ce qu'on veut. Du moment qu'on peut tapper du code et le compiler/exécuter... et qu'on est pas obligé de tout faire en ligne de commandes.
AGL = Atelier de Génie logiciel : C'est un ensemble d'outils qui doivent couvrir les besoins en termes de génie logiciel. Ca inclus donc bien évidemment un IDE, mais aussi des outils de conception, gestion de configuration, gestion de projet, gestion des exigences, tests...
La notion d'Atelier suppose qu'il y est un minimum d'intégration et d'interfaces entre eux.
RAD : Il faut d'abord se mettre d'accord sur quoi on parle. RAD a la base, c'est "Rapid Application Development" et il s'agit d'une méthodologie, essentiellement basée sur le principe de maquettage/prototypage. L'idée étant de développer des maquettes et prototypes qu'on peut présenter au client tout au long des développements pour que ce dernier puisse réagir au plus tôt et n'attende pas la livraison finale pour se rendre compte que l'appli ne correspond pas à ses besoins.
Ensuite, de la méthode on a rapidement fait l'abus de langage : RAD = Outils RAD.
Ce qui donne un AGL qui le plus souvent se limite à un IDE orienté : Je fais tout graphiquement en cliquant à droite à gauche.
Personnellement, je trouve qu'il suffit de regarder une appli VB ou Delphi pour se rendre compte des limites du RAD :
- On développe tout en prenant des composants tout fait, qu'on configure à coup de propriétés en espérant parvenir au résultat voulu.
- Sauf que les composants en question vont certes être capable de faire ce qu'on veut, mais ils en feront également un peu plus, pour le cas où on se trouverait dans un cas qu'ils peuvent gérer d'une certaine façon, mais qu'on ne leur demande pas.
- Tôt ou tard, le composant en fait un peu trop, et on tombe sur des avalanches de bug dû à des effets de bords introduits par ces composants.
- Au lieu de gagner du temps pour pouvoir se concentrer sur les tâches essentielles de l'appli, on passe son temps à faire des verrus pour supprimer des comportements et effets de bords non désirés.
Le pire dans tout ça, c'est que le plus souvent, on ne sait même pas que le composant va faire telle ou telle chose en plus. On ne s'en rend pas compte au moment des tests, et sa explose une fois en prod.
Autre problème qu'on rencontre très rapidement (remarque c'est la même chose avec les frameworks trop évolués) : Les composants sont conçus pour pouvoir faire un maximum de choses et être réutilisés dans un maximum de situations différentes.
Du coup, ce sont de vrai usines à gaz qui effondrent les perfs inutilement. Au final, tu es obligé de réécrire complètement les composants qui étaient censés te faire gagner du temps pour pouvoir avoir un résultat satisfaisant.
Donc en conclusion, je dirais plutôt que le RAD permet à des débutants qui maitrisent mal leur développement d'arriver malgré tout à un résultat moyen.
En revanche, l'ingénieur expérimenté atteind vite les limites du RAD, et pour pouvoir les dépasser, il faut y renoncer ! (ce qui ne veut pas dire qu'il faille pour autant renoncer aux outils, Delphi permet aussi de faire du très bon code).
ok
je pense que là , tu te trompes de coupable.Le pire dans tout ça, c'est que le plus souvent, on ne sait même pas que le composant va faire telle ou telle chose en plus. On ne s'en rend pas compte au moment des tests, et sa explose une fois en prod.
Si l'utilisateur utilise un composant d'une façon différente pour lequel on l'a formé à l'utiliser, ce n'est pas la faute du composant.
Par exemple (je caricature), prenons une liste déroulante permettant de sélectionner une personne. Si par le plus grand des hasard, l'utilisateur s'aperçoit qu'il peut sélectionner plusieurs personne en même temps, alors que son métier et sa formation lui a inculqué d'en sélectionné qu'une, alors la personne est responsable de l'erreur, et non pas l'outil/composant.
Pour la définition de Framework, je reste sur ma position. Pour moi ce n'est qu'un ensemble de fonction/classes englobant des processus rébarbatif, connus et standardisé.
Pour ma part, j'ai tendance à nettement séparer mes outils en fonction de ce que je veux faire...
Par exemple, j'ai beau être un fanatique de Delphi, je tire au canon direct sur le premier qui veut tenter de me faire un module "système" avec.
Inversement, entre faire une IHM complexe avec Visual C++ et la faire avec Delphi, y'a pas photo non plus : quand le développeur sous Visual en sera encore à mapper ses messages pour enfin avoir 3 colonnes dans son contrôle, celui sous Delphi aura fini l'IHM qui n'attendra plus que le code réel, et en multilingue en prime...
Par contre, j'estime qu'un bon RAD doit impérativement être extensible : je n'apprécierais pas autant Delphi s'il n'était pas possible de créer ses propres composants, y compris en mode conception !! La VCL est, en plus, une librairie extrêmement bien faite, avec suffisamment de niveaux d'abstraction pour pouvoir faire à peu près n'importe quoi.
Les tests doivent également être possibles facilement, et là, la vitesse de compilation a une importance non négligeable. Les RAD qui mettent 3 heures à compiler (merci CL, ou encore pire, GCC...) ne sont PAS des RAD, point !! Le "R" de "RAD", c'est "Rapid", et passer 20 minutes à compiler quand d'autres RAD le font en 6 secondes, y'a pas photo à mon sens.
Côté frameworks, je suis par contre nettement plus réticent, surtout s'ils sont installés au niveau de l'OS et non pas "embarqués" dans le code exécutable final (ex : VCL Borland, pas nécessaire de la déployer sur l'OS même si c'est possible).
D'une part, les incompatibilités entre les différentes versions sont nombreuses, la rétrocompatibilité pas toujours excellente, et si jamais la technologie prends une claque c'est la cata : tout à refaire pour garantir la maintenabilité...
Pour moi, une "bonne" application se base donc sur une IHM développée en RAD, et des librairies (DLL/SO) écrites en langages spécialisés effectuant le traitement réel, éventuellement au travers d'un wrapper si nécessaire. Chaque module spécialisé (IHM incluse) doit pouvoir être refondu, inclus en changeant de technologie, sans remettre en cause les autres modules.
De plus, si l'on peut générer automatiquement du code (ex : couches de communication ou de test), c'est pas plus mal.
Mac LAK.
___________________________________________________
Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.
Sources et composants Delphi sur mon site, L'antre du Lak.
Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.
Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO
Je suis d'accord avec tout ce que tu dis, Mac, sauf ceci...
Là tu prends déjà un parti pris, qui n'est même pas évident que tu aies le droit (ou le loisir) de prendre :
Faire des DLL/SO suppose de les fournir séparément et que d'autres (éventuellement), puisse les utiliser..
On peut vouloir (ou être contraint) à ne fournir qu'un exécutable.
De même pour l'IHM : que le développement soit fait en RAD, soit (et même en plus que RAD, en prototype), entièrement d'accord.
Cependant, rien n'est moins sûr pour l'appli finale...
Par contre, quand tu dis :
c'est ce que je m'éreinte à faire comprendre , que ce soit dans ce genre de débats ou dans la partie Conception..
Et visiblement ce n'est pas la manière de penser la plus partagée...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Effectivement, on n'a pas toujours le choix... Sauf quand c'est moi qui décide, où je l'impose !
Après, si ça vire au truc monolithique inmaintenable, c'est la faute de celui qui a pris la décision de ne pas écouter les avis de ceux qui connaissent mieux que lui. On joue hélas souvent les Cassandre, en milieu pro...
Même sans forcément rendre les DLL réutilisables !! C'est surtout, pour moi, le fait d'avoir un module testable à part entière, et qui n'a donc pas besoin d'être re-validé lors d'une évolution s'il n'est pas binairement modifié. On passe juste les tests de non-régression, et zou, quelques jours de validation gagnés.
Disons qu'avec un BON RAD, l'appli finale n'est que l'évolution du prototype... Ceci étant dit, j'arrive à le faire avec Delphi / C++ Builder, mais les autres RAD que j'ai pu tripoter (peut-être pas forcément avec autant de connaissances dessus que les RAD Borland, je le reconnais) n'offraient pas cette possibilité, du moins pas au niveau qu'offre Borland.
C'est quand même les seuls RAD que j'ai vu qui permettent de passer une application en multilingue a posteriori sans coûter plus cher (en temps) que si on l'avait prévu dès le départ...
Tu n'es pas le seul : je me tue à faire comprendre que la documentation doit toujours être en accord avec le code (merci Doxygen et équivalents) et en français / anglais irréprochable, que le code doit être analysé statiquement (Lint et autres outils du même genre), et que chaque module doit être testable séparément et de façon automatique (en gros, "run module.test" et on a le résultat directement intégrable dans le cahier de recettes). Si j'allais jusqu'au bout de ma démarche, le code serait en plus passé au "beautifier" avant d'être mis en gestion de configuration, et on passerait également un outil de vérification des règles de codage...c'est ce que je m'éreinte à faire comprendre , que ce soit dans ce genre de débats ou dans la partie Conception..
Et visiblement ce n'est pas la manière de penser la plus partagée...
Tout comme je me tue à dire que lorsque l'on découvre un bug, il faut ajouter un test à la batterie automatique permettant de le déclencher avec l'ancienne version, de montrer qu'il n'est plus là avec la nouvelle, et intégrer d'office ce test à la série de tests de non-régression.
Mais bon : les décideurs financiers semblent ne pas comprendre que filer 10% de temps de développement en plus et livrer un truc carré à un client (éventuellement avec des dérogations, mais au moins, elles sont CONNUES) coûte moins cher que de passer les corrections en garantie, ce qui a en plus souvent tendance à agacer le client...
Et je ne parle même pas du fait que reprendre un code deux mois après est plus "lent" que de faire de BONS tests alors que l'on est en plein dans le cambouis !
Mac LAK.
___________________________________________________
Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.
Sources et composants Delphi sur mon site, L'antre du Lak.
Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.
Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO
Les réflexions de Franck Soriano sont le fruit d'une longue experience sur le RAD et je partage ses conclusions.
Lorsqu'il dit que les composants font plus qu'on ne le demande, un bon exemple, c'est le 5ème défit Delphi pour faire un Sudoku Solver. Il n'y a aucun composant VCL qui me convient vraiment pour réaliser la grille, si ce n'est le TDrawGrid, mais il faudrait le "trafiquer" un peu, et utiliser un descendant de ce dernier en le bridant sur certaines fonctionnalités, ce n'est pas respecter le LSP de ce que j'ai appris grâce aux membres expérimentées du C++. En revanche, il est tout à fait possible de créer son propre composant VCL en la dérivant d'un composant de base TCustomControl ou autre chose.
Un autre point délicat, c'est la floppée d'événements déclenchées par les contrôles orientés données, et si on code les événements sur les différents contrôles, il faut faire gaffe à l'ordre dans lequel ils se déclenchent pour ne pas arriver à des comportements bizarres.
Un Framework, si on prend la traduction litérrale de l'anglais en français, c'est cadre de travail, et je trouve cette définition tout à fait adaptée. Mais il faut faire attention aux oeillères et se dire qu'on pourrait faire autrement que ce que le framework propose et donc être "créatif", tout en exploitant les briques de base du Framework. Sur ce point, Souviron devrait certainement exceller pour réaliser des composants graphiques, car en C, il n'y a aucun framework défni, c'est le développeur qui décide.
Encore une fois ceci est totalement faux ! Lisez les tests que j'ai effectué sur des requêtes simplissimes sur différents SGBDR !
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Envoyé par benwit Voir le message
Pour résumer, pour moi, le principale avantage d'un ORM, c'est l'indépendance par rapport à la base de donnéesFaux suivant le sens de l'indépedance, de quelle indépendance on parle ?
Dans le cas de OpenObject, on est indépendant sur le fait qu'on a pas à créer les tables, les champs, les relations car c'est le framework qui le fait. Par contre, on est contraint que ce soit PostgreSQL , donc là on est plus indépendant de la base de données.
@SQLPro: n'y aurait-il pas une erreur au niveau du fil de discussion, a mon avis ce post est arrivé au mauvais endroit.
En fait, c'est ce que j'ai cru également mais plus haut dans ce fil, j'ai réutilisé des arguments que j'ai posté dans le fil de discussion auquel tu dois faire allusion.
Il est manifeste que SQL Pro a un avis tranché sur la question et n'hésite pas à le faire savoir. Ce qui me désole, c'est le manque d'argumentation et sa méconnaissance des ORMs.
OK, le standard SQL n'est peut être pas aussi standard qu'il le dit mais si SQLPro avait utilisé hibernate, il aurait vu que les requêtes sont fabriquées par le framework en fonction du dialecte et qu'elles ne sont pas les mêmes d'une base à une autre. Ce qui est d'autant nécessaire quand on utilise des fonctionnalités non standard (identifiant auto généré, pagination des résultats, ...)
Par indépendance, je parle :
- pour une grande majorité d'application de gestion (pas pour toutes les applications du monde non plus)
- de changer de SGBD sans avoir à faire de nouveaux développements (juste quelques modifications dans les fichiers de configuration).
Si on comprend et accepte ce que je veux dire par indépendance, je maintiens que l'indépendance au SGBD est un avantage de l'ORM Hibernate.
Si vous êtes d'accord, venez témoigner, sinon, argumentez.
Est-ce qu'avoir des requêtes dynamiques spécifiques à un SGBD n'est pas pour lui une indépendance ? Est-ce que l'indépendance est toujours requise, Est-ce que l'impact sur les performances n'est pas crucial sont d'autres débats.
Pour conclure, j'ai lu les références documentaires que SQLPro cite, son article, etc ... J'admets qu'il a de bons arguments et je demande qu'à être convaincu , surtout que depuis, j'ai mis un peu d'eau dans mon vin et l'indépendance comme j'ai pu le constater nécessite parfois (des applications un peu compliquées) quelques adaptations (+ que le simple changement de dialecte) sans parler du temps passé à appréhender l'outil.
Néanmoins, comme toutes les personnes passionnées par un domaine (ce que j'admire et comprends).
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
La meilleure façon de prédire l'avenir, c'est de l'inventer.
Ca a déjà était dit mais je le répète, un framework ce n'est pas seulement un ensemble de fonctions. J'ai bossé rapidement sur des projets que je ne connaissais pas et le fait de retrouver le même framework (Symfony) m'a permis de faire des modifs tout de suite sans soucis et sans doc technique.
De plus, ce n'est pas une boîte noire, si il y a une erreure que l'on ne comprend pas, il suffit de regarder dans les sources d'où elle vient. Enfin en général ce n'est pas nécessaire.
Au sujet des ORM, je ne comprend pas pourquoi certains ne veulent pas les utiliser. En plus de l'indépendance avec le sgbd, ça fait gagner du temps, beaucoup de temps. Là encore, ce n'est pas une boite noire, il ne faut pas être neuneu et dire, oh bas c plus lent qu'avec une requete sql écrite à la main. Vous pouvez regardez les requetes générées et si c'est nécessaire faire des modifications. Par exemple, dans certains cas, on a pas besoin d'hydrater les objets, c'est faisable avec tout bon ORM.
Pour résumer mon point de vue, les outils qui permettent de ne pas réinventer la roue sont plus que bon à prendre tant que ce ne sont pas des boites noires (éviter donc Micro*%£¨*).
Sur l'expérience que j'ai eu cette année, je peux dire que le temps d'apprentissage a largement était compensé par les gains de dév. Et il y aura encore des gains quand d'autres développeurs devront bosser sur mon travail.
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