Discussion :

[danyclassique]

De :artemus24
(((*Non, il ne s'agit pas de travailler plus rapidement mais de travailler correctement. Autrement dit de laisser aux développeurs le temps nécessaire pour faire du bon travail.
Et quand on maitrise son sujet, alors oui, on travaille plus rapidement. Donc je ne suis pas d'accord, car il ne faut pas mettre la charrue avant les bœuf*)))

Explication qui a deux goutes d'eau pres reflete ce que j'ai deja ecris .



De :artemus24
(((*Non, il ne s'agit pas de travailler plus rapidement mais de travailler correctement. Autrement dit de laisser aux développeurs le temps nécessaire pour faire du bon travail*))))

Je pense qu'il est important de souligner que si au jours d'un entretien d'embauche on dit cela
on risque apres tres peut de temps et repetition
de chercher du travail ailleurs. qui puis est dans une startup en penurie d'argent au tout debut.

Non mais faut arreter de ce cacher la face ,le monde du travail est extremmement difficile nous somme plus a l'age ou 20 goto 10 et un amstrad 464 ,et hoppp on impressionne tout le monde .
Il y a un stress econnomique et technologique qui oblige les societes a se comporter de la sorte et evidement cela se ressent jusqu'au dev A MON GRAND REGRET BIENSUR.

C'est peut etre deplorable mais.....

Je reprecise au passage,
que je ne suis pas chef d'equipe,
(Pour l'instant toujours refuser se poste),
mais bien et tout simplement dev et fier de l'etre , etant base ces dernieres annees a l'etranger ,
a mon humble avis , pour garder sa place en tant qu'informaticien en dehors du territoire francais voir meme je suis sur en france :-) ,en tout cas c'est ce que je ressent :-) , mais je peut me tromper :-) , cela ne se fait pas en prenant son temps par la reecriture d'une class tout simplement parceque le desin pattern
ne lui convient pas, surtout quand celle-ci ne fait qu'appeler des objects disposables automatiquement qu'apres using."ne pas prendre mot pour mot ce que je dit :-)".



j'ai vu malheuresement pas mal de collegues moi y compris quand je debutais , qui se sont fait severement sanctionner par ce genre de comportements ,je cite :
"Prendre son temps pour programmer mais bien",

car ce qu'on nous repond avant la sanction c'est...
(prendre son temps pour programmer ce que quelqu'un d'un peux moins competent et moins payer peut faire deux fois plus rapidement) n'est pas productif .

Tout ca par l'unique raison d'avoir le pretention de dire " prendre son temps mais travailler correctement".


Il y a des ingenieurs voir tout simplement autodidactes qui travaillent extremmement bien et vite et pas chere en plus .
ALors pourquoi s 'en priver!!!!!

Au niveau des boulons en chrome sur les voitures et sur d'autres non , annalogue bien reecrite ;-)

[Mat.M]

JQu'es ce que le client veut ?, un programme qui répond a ces besoins, le code ou l'optimisation il s'en fou (ou en tous cas c'est le moins visible), c'est donc la dessus qu'on vas faire beaucoup de concession, en faisant des applications peu évolutive,..
C'est peut être une des explications sur le fait que les logiciels bouffe de plus en plus de ram

c'est exact , on pourrait dire construire des usines-à-gaz et malheureusement en milieu professionnel c'est de plus en plus cas.

Pourquoi n'y a-t-il absolument plus du tout de vraie musique classique ? Pourquoi tous les chefs d'oeuvre du genre ont-ils au minimum 50 ans, deux générations complètes ? Même principe que pour l'informatique.
.

c'est un autre débat...
les chefs d'oeuvre ont au minimum 50 ans c'est parce qu'on a ne fait que refaire du jeune avec du vieux.
Quant on voit le génie cinématographique d'un Sergio Leone qui était le maitre dans son genre, les films actuels sonnent trop creux pour moi.
Je ne voudrais pas faire du hors-sujet mais si tu regardes ne serait-ce que le Bon,la Brute et le Truand , les cadrages,les focales, les profondeurs de champs,les atmosphères plus aucun réalisateur de cinéma n'est capable de faire ça aujourd'hui.
Ce qui rejoint quelque part pourtant le sujet principal c'est qu'aujourd'hui on a tendance à faire plus du jettable qu'autre choses y compris en informatique
D'ailleurs si on regarde la Société dans son entièreté les bases ont été jetées il y a au moins 2000ans avec les philosophes grecs comme Platon ou Aristote
donc de nos jours on n'invente plus rien.
Pour ce qui est du culturel et de l'entertainment ,depuis Corneille et Molière je ne crois pas que l'on ait vraiment crée du neuf la société demeure toujours la même.

[Artemus24]

Salut à tous.

Explication qui a deux gouttes d'eau près reflète ce que j'ai déjà écris.

Pas du tout. Je reprends ci-après le point essentiel de ta réflexion :

... mais tout aussi bien du rapide fonctionnel a la satisfaction du client

Donc tu mets l'accent sur le respect des délais et de répondre aux besoins du client.

Inversement, même si je respect le cahier des charges, je mets l'accent sur la nécessité de bien développer.
Après tout, n'est-ce pas ce que l'on me demande de faire. Et ce n'est pas exactement la même chose.
Ou alors, je n'ai pas compris ton message, même après l'avoir relu une seconde fois.

Je pense qu'il est important de souligner que si au jours d'un entretien d'embauche on dit cela on risque après très peut de temps et répétition de chercher du travail ailleurs. qui puis est dans une startup en pénurie d'argent au tout début.

Ce que cherche les patrons, se sont des compétences qui ont le respect du travail bien fait.
Maintenant, si tu penses que le patron a toujours raison, je pense que tu n'as rien compris de ta fonction dans une entreprise.
Tu n'es pas là pour passer le balai et la serpillière quand ton patron te le demande. Tu es là pour répondre à un besoin et ce besoin est contractuel.
Maintenant s'il abuse de sa position dominante, tu as vraiment un problème dans ton entreprise.

Tu as toujours la possibilité de t'expliquer avec ton patron, maintenant s'il n'est pas prêt à le faire, c'est que tu es face à quelqu'un d'entêté.
Je sais qu'aujourd'hui le contexte a grandement changé, mais si tu te laisses marcher sur les pieds, ce patron n'aura jamais aucun respect pour toi.

Non mais faut arrêter de ce cacher la face ,le monde du travail est extrêmement difficile nous somme plus a l'age ou 20 goto 10 et un amstrad 464 ,et hoppp on impressionne tout le monde .

Franchement, je ne sais pas dans quel monde tu vis, mais il faudrait revoir ta conception de l'informatique.
Aujourd'hui n'importe qui possédant un ordinateur se croit informaticien. Le niveau a beaucoup baissé dans les SSII et les développeurs n'ont même pas les bases requises pour travailler normalement.
Ce n'est pas dans une SSII que l'on va pour se former, tout au contraire. Si tu n'es pas à la hauteur, on te vire, même si tu es sur-diplômé.

Je pense que tu fais une confusion entre les qualités nécessaire pour être un bon développeur et ce que te demandes ton patron. Ce n'est pas exactement la même chose.
Il y a d'un coté l'impératif du respect des délais qui sont d'ordre commercial et de l'autre, le respect du cahier des charges, c'est-à-dire du travail bien fait qui d'ordre technique.

Quant on voit le génie cinématographique d'un Sergio Léone qui était le maître dans son genre, les films actuels sonnent trop creux pour moi.

Entièrement d'accord avec toi. Mais voilà, ce genre d'oeuvre cinématographique devient un classique du genre.
Pourquoi les scénaristes font-ils des films creux ? La réponse est, comme dans l'informatique, la mise à la disposition des moyens nécessaire pour réaliser ce travail.

Je ne voudrais pas faire du hors-sujet mais si tu regardes ne serait-ce que le Bon, la Brute et le Truand, les cadrages, les focales, les profondeurs de champs, les atmosphères plus aucun réalisateur de cinéma n'est capable de faire ça aujourd'hui.

Et que fais-tu du scénario ? Reprends les vieux films français, il y avait des scénarios bien ficelés, même si le budget n'était pas à la hauteur d'aujourd'hui.
Je pense entre autre, au film : "l'assassin habite au 21". L'intrigue pour l'époque était haletante.
Maintenant, aucune histoire, tout le film tourne autour des effets spéciaux, de gros budgets, des stars royalement payé, et le tout filmé en quelques semaines.

Le cinéma comme l'informatique ont été kidnappés par les commerciaux. La règle est de faire de l'argent !

@+

[danyclassique]

Chacun son point de vu !!
Je respect celui la
Mais un point de vu ne reflete pas automatiquement la cadence social d'un employe au sein de la societe pour laquelle il travail .


Je ne vois absoluement pas le raport entre ce sujet et comme tu dit .
"Tu n'est pas la pour faire autre chose que programmer " et , tu cite "Peur de ton patron".
Desole mais je ne comprend plus le sens du debat qui a legerement bifurque de "de nos jours logiciels rate ....".

Au passage ,et un peut plus personnel, jusqu'a present ,il s'est toujours instaurer un climat de bonne entente dans les lieux auquelles j'ai travaille sans pratiquement jamais aucune consecion psychologique et
encore mois un climat militaire.
peut etre que cela t'es arrive tres souvent et donc ,c'est pour cela que je comprend ton point de vu mais ,dans ce cas la ,je te conseil vivement de changer quelque chose.

[Fleur en plastique]

Le premier message est plutôt vrai. D'ailleurs, avec les exigences modernes actuelles des clients, notre équipe de développement a identifié dans notre code un nouveau pattern (motif de conception). On l'a appelé "Gas Factory".

[zulu1]

Oui, c'est vrai. J'avais dit à Sogeti qu'on devait revenir à la planche à dessin concernant un soft et il l'on mené à terme. Du coup One4eu a dû se taper un brol comme générateur de cv. C'est la misère quand les projets sont pilotés par les deadlines.

[thoip]

le principal problème c'est qu'il n'y a plus de développeurs dans beaucoup de cas mais des programmeurs. On leur dit code cela ils codent sans reflechir aux besoins derrière.

Les spécifications sont faites maintenant par des architectes qui ne codent pas et qui des fois n'ont jamais codés. Résultat des spécifications qui ne pensent pas aux cas limites.

Il y a un autre problème c'est la gestion même des bases de données. Ok faire une base de données l'enrichir l'exploiter. Mais qu'en est il des scripts de contrôle de cohérence de données. La plupart du temps c'est inexistant. Pourquoi.Qu'on ne me dise pas que cela n'a pas été budgeté. Il n'y a pas que cela derrière. C'est un travail qui passe à la trappe parce que celui qui crée la base de données n'a que les spécifications de la base pas à quoi va servir la base qui est le rôle normalement dévolu au développeur.

Le vrai problème aujourd'hui c'est la parcelisation des métiers de l'informatique touchant au coeur d'un programme.

Plus on fragmenteen de nouveaux métiers histoire d'assurer sla qualoité de développements plus on crée de bugs d'incompréhension

[Artemus24]

Salut thoip.

Le vrai problème aujourd'hui c'est la parcellisation des métiers de l'informatique touchant au cœur d'un programme.

Pas vraiment ! Je dirais à chacun son métier.
Or aujourd'hui, on demande beaucoup trop de choses à un développeur. Et de ce fait, la compétence n'est pas au rendez-vous.
On ne peut pas tout connaitre et faire du bon travail sans expérience.
Oui, mais voilà, on ne s'improvise pas administrateur de base de données sans connaitre par exemple merise et en particulier la façon de gérer des données au sein d'un projet.
Ou encore savoir rédiger un cahier des charges sans connaitre parfaitement les besoins d'un client.

Qu'à cela le tienne, au verra les problèmes au fur et à mesure qu'ils vont se présenter.
Et après, il ne faut pas s'étonner que le projet ne tient pas les dates de livraisons ou de la multitude de bug que le client va rencontrer.

Pour reprendre ta remarque, je dirais qu'il y a un réel problème de compétence à la base, mais surtout que l'on ne met pas les moyens dans ce que l'on veut faire.

@+

[Laurent 1973]

N'oublions pas non plus, qu'en France, à 30-35 ans on doit en avoir fini avec la technique et être devenu au moins "chef de projet" (sinon, on a raté sa carrière professionnel)
Dans ce contexte, dès que l'on deviens compétent techniquement .... et bien on ne fait plus de technique.

Donc, ne pas s'étonner que le développement est fait, de façon très cloisonné, par des gens peu expérimentés qui n'ont pas forcement envie d’acquérir de la compétence vu que dans 5 ans ils seront chef.

[el_slapper]

(.../...)Le vrai problème aujourd'hui c'est la parcelisation des métiers de l'informatique touchant au cœur d'un programme.(.../...)

ça. 100% d'accord. N'en déplaise à Artemus24, mais le découpage d'un projet en "compétences" est de la foutaise. début 2014, j'ai passé un entretien pour une mission chez une banque qui fait aussi de la distribution de courrier. Leur méthode de travail:
_une personne fait l'expression de besoin
_une autre la spec fonctionnelle générale
_une autre la spec fonctionnelle détaillée
_une autre la spec technique générale
_une autre la spec technique détaillée(moi si j'avais été pris)
_une personne chez un fournisseur externe code
_une autre personne chez le même fournisseur "met à disposition"
_une autre personne se fade les tests unitaires
_une autre personne fait les tests d'intégration
_et après, je ne sais plus, ils n'ont pas poussé plus loin la description

On travaille sur des sujets complexes, ou chaque étape passe-plat fait perdre aux intervenants une bonne partie du contexte. A mon sens, le devrait y avoir en tout et pour tout, sur le chemin :
_une personne métier qui dit le quoi?
_une personne développement, qui se charge du comment
_une personne test, qui vérifie la conformité

Au maximum.

Après, on peut avoir des transversaux qui donnent des coups de main, des DBA, des gens système, des urbanistes... Mais pas sur le chemin propre de la chose à réaliser. C'est le meilleur moyen de se perdre en cours de route.

[Artemus24]

Salut el_slapper.

ça. 100% d'accord. N'en déplaise à Artemus24, mais le découpage d'un projet en "compétences" est de la foutaise.

Vu comme tu le présentes, je suis d'accord avec toi.

Quand je parle du découpage, je parle des compétences des grands corps des métiers de l'informatique :
--> l'exploitation (batch JCL)
--> l'administration des bases de données (DB2)
--> l'administration du transactionnel (CICS)
--> les analyses.
--> les testeurs.
--> chef de projet.
--> le développement.

En gros système, tu travailles presque tout le temps avec les mêmes :
--> ceux de l'exploitation quand tu livres une nouvelle application.
--> ton équipe, et en particulier ton chef de projet que tu vas voir si tu as un problème.
--> et les analyses.

Donc cela ne fait pas tant de gens que cela.

@+

[Ecva233]

Plus on fragmenteen de nouveaux métiers histoire d'assurer sla qualoité de développements plus on crée de bugs d'incompréhension

Je ne suis pas sur que l'objectif de fragmentation d'un projet informatique, soit d'assurer la qualité des composants développés.

Les différents objectifs que j'ai pu comprendre étaient :
- la possibilité de paralléliser l'écriture des spécifications fonctionnelles et techniques
- la possibilité de paralléliser les développements, une fois les spécifications terminées
- raccourcir les jalons de livrable
- éviter que la connaissance d'un projet ne repose que sur un minimum de personne, et devienne de ce fait incontournable


Tout cela pour raccourcir au maximum le délai entre l'expression du besoin d'un client et le déploiement de la solution répondant au besoin, utilisable par le client.

Je ne dis pas que c'est la panacée, mais la vision du client prime. Il acceptera de payer un peu plus cher un projet, si celui-ci abouti en 3 à 4 mois, plutot que de payer moins cher un projet qui aboutira dans 1 ans. Aujourd'hui c'est le métier qui dicte sa loi.

[el_slapper]

Je ne suis pas sur que l'objectif de fragmentation d'un projet informatique, soit d'assurer la qualité des composants développés.

Les différents objectifs que j'ai pu comprendre étaient :
- la possibilité de paralléliser l'écriture des spécifications fonctionnelles et techniques
- la possibilité de paralléliser les développements, une fois les spécifications terminées
- raccourcir les jalons de livrable
- éviter que la connaissance d'un projet ne repose que sur un minimum de personne, et devienne de ce fait incontournable


Tout cela pour raccourcir au maximum le délai entre l'expression du besoin d'un client et le déploiement de la solution répondant au besoin, utilisable par le client.

Je ne dis pas que c'est la panacée, mais la vision du client prime. Il acceptera de payer un peu plus cher un projet, si celui-ci abouti en 3 à 4 mois, plutot que de payer moins cher un projet qui aboutira dans 1 ans. Aujourd'hui c'est le métier qui dicte sa loi.

On peut découper dans l'autre sens. On parallélise : l'un développe la partie compte, un autre la partie carte, un autre la partie prêts..... Là, oui, ça peut marcher. Mais quand tu découpes le chemin de chaque élément(et non pas entre les éléments), tu ralentis, en plus de perdre de l'information souvent importante.

[Ecva233]

On peut découper dans l'autre sens. On parallélise : l'un développe la partie compte, un autre la partie carte, un autre la partie prêts..... Là, oui, ça peut marcher. Mais quand tu découpes le chemin de chaque élément(et non pas entre les éléments), tu ralentis, en plus de perdre de l'information souvent importante.

El Slapper tu prêches un converti ( :-) ), le souci c'est que le management n'a pas la même vision, imposée par le métier : raccourcir et maitriser les couts en parrallélisant les tâches, quitte à ceux qu'une partie des ressources ne soient plus que des presses boutons, sans comprendre ce qu'ils font.

[Artemus24]

Salut à tous.

On peut découper dans l'autre sens. On parallélise : l'un développe la partie compte, un autre la partie carte, un autre la partie prêts.....

Le but de la gestion d'un projet est de raccourcir ce que l'on appelle le chemin critique. Si l'on peut paralléliser certaines tâches, c'est bien.
Mais ce que l'on cherche à faire, c'est compresser le temps nécessaire à son maximum pour réduire les délais de livraisons de chaque tâche.
Et ne pas oublier que certaines tâches peuvent commencer quand d'autres se terminent. Il y a donc de l'interdépendance.

Plus il y a d'intervenants et plus on parallélise. Sauf que le maillon faible reste l'incompressibilité d'une de ces tâches qui va conditionner le chemin critique.

Je comprends mieux votre vision de votre métier. Pour le reste, je suis d'accord.

Dans ce contexte, dès que l'on devient compétent techniquement .... et bien on ne fait plus de technique.

C'est un paradoxe du monde informatique. La technique a toujours été mal considéré par nos patrons et je n'ai jamais compris pourquoi.
Pourtant sans technique, on ne fait rien. On a beau valoriser les analystes, les chefs de projets, ce ne sont pas eux qui développent.
Et la grande innovation a été la sous-traitance. Ce fut catastrophique en terme des délais, mais surtout du respect du cahier des charges.
Confier cette tâche à des personnes n'ayant pas la connaissance du métier du client fut une erreur.
Voire même, on la confiait à des étrangers n'ayant même pas la connaissance linguistique de nos analystes et chefs de projets.

Et bien sûr, tout cela pour réduire les coûts alors qu'au final, par de multitudes retours sur le travail, les coûts ont augmenté.

@+

[el_slapper]

(.../...)C'est un paradoxe du monde informatique. La technique a toujours été mal considéré par nos patrons et je n'ai jamais compris pourquoi.
Pourtant sans technique, on ne fait rien. On a beau valoriser les analystes, les chefs de projets, ce ne sont pas eux qui développent.
Et la grande innovation a été la sous-traitance. Ce fut catastrophique en terme des délais, mais surtout du respect du cahier des charges.
Confier cette tâche à des personnes n'ayant pas la connaissance du métier du client fut une erreur.
Voire même, on la confiait à des étrangers n'ayant même pas la connaissance linguistique de nos analystes et chefs de projets.

Et bien sûr, tout cela pour réduire les coûts alors qu'au final, par de multitudes retours sur le travail, les coûts ont augmenté.

@+

Non, les vraies raisons de ce découpage en tronçonnage, c'est politique : les non-techniques ne veulent pas que les techniques prennent le pouvoir. Quitte à ce que ça coute beaucoup plus cher.

[Ecva233]

Non, les vraies raisons de ce découpage en tronçonnage, c'est politique : les non-techniques ne veulent pas plus que les techniques prennent le pouvoir. Quitte à ce que ça coute beaucoup plus cher.

J'ai eu la chance ou la malchance de vivre cette époque là ou du moins la fin de cette époque là.

En tant que simple Analyste Porgrammeur, tu pouvais faire un doigt/bras d'honneur à ta hiérarchie, t'en aller et le jour suivant travailler sur une autre mission, sans état d'âme. C'est en partie, ce que m'a appris le fait de travailler dans le privé en info en observant le comportement d'une profession : aucun état d'âme. Je travaille pour moi et moi seul, surtout quand tu es en SSII.

Tu n'avais aucune pression professionnelle et ta hiérarchie le savait. Tu pouvais dire "non" au métier, et les envoyer chier.

Tu avais la possibilité de dire "cela sera comme cela et pas autrement, parceque je l'ai décidé" et quel qu'en soit les conséquences.

Tu pouvais devenir central dans la prise de décision, d'une évolution demandée par le métier.

Un simple rouage, mais indispensable, pouvait tout arrêter ou du moins ralentir un projet. Cela était aussi la reconnaissance par le pouvoir de nuisance.

C'est à mon sens une des raisons pour lesquelles nous avons perdus ce "pouvoir" : le risque d'abus.

[Invité]

Un exemple précis toi tu fais un moteur à la main en OpenGL full-Linux. Combien de temps as-tu passé pour avoir le résultat actuel? Et si tu étais passé à Unity ou à UE 4?

Unity n'existe pas depuis des années, et puis, de toute évidence, comme toute les nouvelles technologie, ça ne laisse aucune liberté sur les librairies que l'ont souhaite utiliser, ni sur le code source, donc si il y a un bug ou qu'on a besoin de rajouter un fonctionnalité par la suite, on est contraint de faire avec.

Donc oui ce genre de technologie c'est un gain de temps dans un premier temps mais c'est trompeur car ça peut t'en faire perde énormément par la suite..., rien ne me dis que unity gère des techniques tel que le weighted blended OIT ou encore des volumes englobant sur des games objects par exemple.

Un autre exemple est lorsque j'étais dans une boîte et que l'on souhaitait modifier un programme fait avec visual basic 2005, impossible de retrouver cette version, maintenant on est déjà à visual studio 2015 et c'est :

-Lourd (un jour pour l'installer, très lent à s'ouvrir)
-La galère pour lier les dépendances.
-Du code qui compile parfaitement avec cmake et gcc sous linux mais le compilateur de windows ne le prend pas. (Je parle de code c++ bien sûr par les langages récent qui demandent de maîtriser un tas de concept et me font perde un temps fou à lire des tas de bouquin.)

Non sincèrement avec les nouvelles technologie ont peut aussi bien perdre sont temps même plus de temps que de recoder une bibliothèque toute simple tel que la mienne.

[DonQuiche]

Donc oui ce genre de technologie c'est un gain de temps dans un premier temps mais c'est trompeur car ça peut t'en faire perde énormément par la suite...

Dans un premier temps ?! Mais faire un moteur de jeu et éditeur complets de nos jours c'est un travail en centaines d'années-hommes !

Si tu t'appelles Ubisoft je peux comprendre le raisonnement.


Alors bien sûr tu peux toujours trouver telle ou telle technique qui sera inutilisable avec le pipeline d'un moteur mais ceux-ci sont relativement personnalisables et couvrent 99% des besoins. Et si tu tombes dans le 1%, la bonne réponse n'est certainement pas de développer ton propre moteur.

[SurferIX]

Dans un premier temps ?! Mais faire un moteur de jeu et éditeur complets de nos jours c'est un travail en centaines d'années-hommes !

Si tu t'appelles Ubisoft je peux comprendre le raisonnement.

Alors bien sûr tu peux toujours trouver telle ou telle technique qui sera inutilisable avec le pipeline d'un moteur mais ceux-ci sont relativement personnalisables et couvrent 99% des besoins. Et si tu tombes dans le 1%, la bonne réponse n'est certainement pas de développer ton propre moteur.

Au vu de ce que tu dis, cela semble vouloir dire "c'est plus facile d'exploiter ce qui existe que d'essayer de faire son truc à soi car c'est beaucoup trop de travail". Je ne suis pas d'accord. Si tu veux vraiment comprendre comment fonctionne un moteur de voiture, c'est pas en roulant et en étant uniquement conducteur que tu y arriveras vraiment. J'ai fait 4 fois mon propre framework avant d'utiliser les autres du marché, et je sais ce qu'il y a de bien, de pas bien, et tous les rouages, et c'est pour cela que je suis bien placé pour donner des explications, et discussions techniques afin que le choix soit le meilleur possible. Tu ne pourras jamais être de bon conseil si tu ne sais qu'utiliser les outils des autres. Symfony et a beaucoup de ses surcouches inutiles, car elles ont été créées dans un cadre et un besoin spécifique. Et je sais de quoi je parle . Même chose pour Lolilolight : le jour où il aura un autre moteur à choisir, s'il en a marre ou qu'il ne peut plus maintenir / faire évoluer le sien, il sera simplement le mieux placé, voire un des meilleurs, pour savoir quel moteur choisir et pourquoi.