Discussion :

[yukihira]

D'expérience, les méthodes Agile sont surtout appliquées quand tout va encore bien dans le projet (notamment au tout début). Cela montre que certains managers sont ouverts, que l'équipe est entendue, que tout le monde travaille main dans la main. Et puis arrive certaines difficultés (deadline en approche, nouveau scope très critique, coupe budgétaire...), et on commence à délaisser l'Agile, et se retourner vers d'autres méthodes plus restrictives, et où l'hiérarchie est très bien définie et applique bien toute son autorité.

Pour moi, tant qu'on n'applique pas les préceptes décrits dans le manifeste Agile, on peut y mettre tous les noms qu'on veut, ce ne sera jamais de l'Agile.
Pour rappel, ces préceptes sont:
- Les individus et leurs interactions plus que les processus et les outils -> dès fois, c'est toute une équipe ou tout un département qui fait son mode autiste, hermétique à toute interaction directe avec les autres, et qui demande tout un processus pour communiquer avec eux.
- Des logiciels opérationnels plus qu’une documentation exhaustive -> très bonnes excuses pour certains "mauvais participants" pour faire du n'importe quoi, avec du code non commenté, et de systèmes mal décrits. Ceux qui vont venir après vous vous remercient.
- La collaboration avec les clients plus que la négociation contractuelle -> tant qu'on est au début du projet, OK. Mais au delà, quand le deadline se fait sentir, quand le livrable ne convient pas tellement aux besoins, on se tourne très vite vers les contrats pour se protéger (et pour attaquer l'autre).
- L’adaptation au changement plus que le suivi d’un plan -> avec un système mal conçu au départ, des besoins fonctionnels non définis, et certaines capacités techniques un peu juste, l'adaptation au changement est plus que compromise.

Pour faire face à tout ça, certaines équipes/entreprises inventent la méthode "super-agile", connue plus communément par la méthode "Larrache".

[foetus]

Ouais fin en fait, c'est quoi concrètements à part de l'administratif Scrum ? Parce que dans le concret, j'arrive vraiment pas à cerner l'utilité du truc pour le dev lambda.

Les termes qui reviennent avec les méthodes de développement sont :

• incrémentale - on va coder le produit par [paquet de] fonctionnalité
• itérative - à chaque itération on a un livrable
• adaptative - à chaque [paquet de] fonctionnalité ou itération (je ne sais plus ), on va s'interroger : est-qu'on a eu un problème ? est-ce qu'une fonctionnalité nécessite plus de temps ? moins de temps ? Est-ce que le client est satisfait ? Est-ce que le budget est OK ? Niveau temps on est dans les clous ? ...
  Cela permet de réajuster tout un tas de choses lors du développement.

Avec les méthodes agiles :

• on ne va perdre des mois à écrire/ signer un cahier des charges. On va intégrer dans l'équipe de développement le client/ un représentant client. Il va dire ce qu'il veut et valider les itérations. On part du principe que les besoins client sont [très] changeants
• à chaque itération, on a un prototype fonctionnel - que le client et les utilisateurs peuvent tester.
• chaque itération est courte : 1 à 4 semaines

Entre les méthodes agiles, il y a aussi de grosses différences
Avec Scrum, on s'intéresse à la gestion du projet - qui fait quoi, les réunions nécessaires, les documents à produire, ...
Avec l'eXtrem Programming, on s'intéresse à la façon que l'équipe de développement travaille - pair programming, Test-Driven Development (TDD), encourage le refactoring partiel de code, ...

Mais les méthodes agiles posent des problèmes :

• petite équipe de pas plus 20 développeurs.
• il faut dans l'équipe 1 - 3 experts (développeurs seniors) - il faut toujours aller de l'avant et être [+ ou -] sûr de ce qu'on fait.
• la documentation. Les méthodes agiles encouragent le self-documenting code - le problème de la documentation c'est la maintenance et sa pertinence (décrire ce qu'elle fait, et non pas comment elle le fait). Mais dans des parties de code très complexe c'est vital. Il y a un compromis à trouver
• le refactoring - cela prend du temps, mais pour avoir un produit qui ne part pas en quenelle c'est vital. Mais cela prend du temps.

[zecreator]

Je connais pas bien Agile, mais à lire les différents examples, c'est appliquable a n'importe quel projet.

Du coup, quand un artisan répond à la demande de me faire une piscine dans le jardin, moi j'ai un budget fixe et des délais. Du coup, comment l'artisan peut mettre en pratique Agile.

Et cet example, c'est tout de même le profil de beaucoup de projet. On demande un devis avant de se lancer dans la production.

J'ai jamais rencontré de client qui me donne pas de contrainte de délai et de budget. Comment Agile gère ça ? On va pas faire bosser les équipes 200 jours, si la prestation n'en couvre que 100.

Il m'est arrivé, sur des missions, de monter une équipe de free-lance, qui me vendaient des jours. Si je devais appliquer la méthode Agile, j'imagine que ce nombre de jours aurait explosé. Du coup, la mission m'aurait coûtée plus chère que ce qu'elle m'aurait rapportée.

[viper1094]

De ce que j'ai pu en lire, c'est un peu comme les limitations sur les chantiers. C'est dans l'intérêt des travailleurs mais ça devient vite intenable.

[zaventem]

Du coup, quand un artisan répond à la demande de me faire une piscine dans le jardin, moi j'ai un budget fixe et des délais. Du coup, comment l'artisan peut mettre en pratique Agile.

Et cet example, c'est tout de même le profil de beaucoup de projet. On demande un devis avant de se lancer dans la production.

Déjà, en pratique, la notion de budget et de délai n'est jamais aussi clair que cela: c'est en général un montant et un délai maximum. "Je veux une piscine, je peux dépenser un maximum de autant et je voudrais qu'elle soit prête pour mes vacances en juin".
Ensuite, je trouve qu'on vend en général mal ce concept quand on parle d'Agile: les gens ne sont pas d'un coup plus où moins compétent quand il s'agit d'estimer les coûts et délais qu'avec n'importe quelle autre méthode. Même dans le cas d'un prix fixe au forfait, les contrats sont souvent suffisamment bien ficelés pour mettre quantité de suppléments à charge du client "parce que voyez-vous, ce point n'était pas dans l'offre". Ce qui change fondamentalement c'est le choix entre rallonger le temps de dev (et donc directement le budget) et enlever des fonctionnalités.

Pour reprendre ton exemple de piscine, tu viens trouver ton entrepreneur et tu lui demandes de rajouter un système de nage parce que tu t'es découvert entre temps une nouvelle passion. Vous allez du coup devoir vous mettre d'accord pour savoir si vous rétrécissez la piscine pour gagner du budget pour la pompe et un peu de temps pour l'installer, si tu mets la main au portefeuille et que tu acceptes de ne l'avoir que mi-juin, que tu laisses tomber cette idée de nage à contre-courant, ...

Les méthodes Agile, ce serait aussi dans ce cas que l'entrepreneur dise à son équipe où creuser le trou et de la laisser gérer qui le fait, avec quels outils,... C'est de mettre en place un moyen une fois la piscine fini ce qui a bien été, ce qui a moins bien été et de capitaliser sur cette expérience pour la prochaine fois.

Les méthodes Agile nécessitent pleins d'applications et des tonnes de documentations; ou un paquet de post-it et une feuille de papier; elles nécessitent des équipes de 5 personnes pour assurer le suivi ou d'un gars un peu sensibilisé. Elles s'adaptent aux besoins (même si malheureusement, cette partie est souvent oublié par ceux qui les imposent) et sont avant tout basées sur le bon sens.

[foetus]

c'est appliquable a n'importe quel projet.

Pour rebondir aux propos de @zaventem, je ne pense que non

Lorsque tu réalises un projet "dit industriel" (essentiellement en C/ C++), comme un système de guidage, un cœur artificiel, un F-135, ... ce sont des projets qui ne changent pas au cours du temps - tu peux prendre le temps pour le réaliser (souvent on parle en années), et je pense que les normes font qu'il faut y aller piano-piano
Les méthodes traditionnelles sont privilégiées - cycle en V

Mais pour un site Internet (ou une application lourde), il va y avoir de l'évolution : en fonction des législations comme le RGPD ou l'article 13, ajout/ suppression des fonctionnalités, changement des modes de payement, ...
Alors au début, le projet peut être assez long pour coder la base, mais ensuite le client peut changer fréquemment.
Et donc les méthodes agiles sont privilégiées - Scrum

[Pyramidev]

Agile ? C'est quoi

C'est ce qui est écrit dans le manifeste agile et les principes sous-jacents au manifeste.

Ouais fin en fait, c'est quoi concrètements à part de l'administratif Scrum ? Parce que dans le concret, j'arrive vraiment pas à cerner l'utilité du truc pour le dev lambda.

Scrum est une méthode définie dans le guide Scrum. Elle spécifie qui est responsable de quoi et quelles sont les réunions.

• Le Product Owner est la personne responsable de la priorisation des tâches. Il ne doit y avoir qu'un seul Product Owner. L'intérêt pour les développeurs est d'éviter d'avoir plusieurs chefs différents qui donnent des priorités contradictoires. Si un développeur a un doute sur l'ordre des tâches à effectuer, c'est au Product Owner qu'il doit s'adresser.
• C'est l'équipe de développement qui est responsable de l'estimation des délais par rapport à la liste des tâches. L'intérêt est d'avoir des délais moins irréalistes.
• L'équipe de développement est responsable comme un tout. L'intérêt pour un développeur est d'éviter d'être bloqué sur une tâche dont il est le seul responsable, avec les autres développeurs qui n'ont pas le temps de partager leurs infos parce qu'ils se focalisent sur ce dont ils sont eux-même responsables.
• Le Scrum Master est la personne qui encourage l'application de Scrum et signale les dérives de l'organisation actuelle par rapport à ce qui est défini dans Scrum.
• Parmi les réunions, il y a le Daily Scrum qui est une réunion quotidienne de 15 minutes dans laquelle chacun dit ce qu'il a eu le temps de faire depuis le précédent Daily Scrum et ce qu'il compte faire dans les 24 prochaines heures. L'intérêt est de savoir qui fait quoi.
• Il y a d'autres réunions, dont la Sprint Retrospective, dans laquelle les participants doivent réfléchir à comment améliorer la productivité.

En pratique, beaucoup d'entreprises disent appliquer Scrum car c'est un argument marketing, mais ne l'appliquent pas.

[viper1094]

Scrum est une méthode définie dans le guide Scrum. Elle spécifie qui est responsable de quoi et quelles sont les réunions.

• Le Product Owner est la personne responsable de la priorisation des tâches. Il ne doit y avoir qu'un seul Product Owner. L'intérêt pour les développeurs est d'éviter d'avoir plusieurs chefs différents qui donnent des priorités contradictoires. Si un développeur a un doute sur l'ordre des tâches à effectuer, c'est au Product Owner qu'il doit s'adresser.
• C'est l'équipe de développement qui est responsable de l'estimation des délais par rapport à la liste des tâches. L'intérêt est d'avoir des délais moins irréalistes.
• L'équipe de développement est responsable comme un tout. L'intérêt pour un développeur est d'éviter d'être bloqué sur une tâche dont il est le seul responsable, avec les autres développeurs qui n'ont pas le temps de partager leurs infos parce qu'ils se focalisent sur ce dont ils sont eux-même responsables.
• Le Scrum Master est la personne qui encourage l'application de Scrum et signale les dérives de l'organisation actuelle par rapport à ce qui est défini dans Scrum.
• Parmi les réunions, il y a le Daily Scrum qui est une réunion quotidienne de 15 minutes dans laquelle chacun dit ce qu'il a eu le temps de faire depuis le précédent Daily Scrum et ce qu'il compte faire dans les 24 prochaines heures. L'intérêt est de savoir qui fait quoi.
• Il y a d'autres réunions, dont la Sprint Retrospective, dans laquelle les participants doivent réfléchir à comment améliorer la productivité.

Dis comme ça ça semble excellent sauf que le problème évident est le suivant. Le réalisme. Dans la théorie et dans la pratique c'est différent

En pratique, beaucoup d'entreprises disent appliquer Scrum car c'est un argument marketing, mais ne l'appliquent pas.

Comme tu dis m'sieur la pyramide, comme tu dis...

[zecreator]

Déjà, en pratique, la notion de budget et de délai n'est jamais aussi clair que cela: c'est en général un montant et un délai maximum. "Je veux une piscine, je peux dépenser un maximum de autant et je voudrais qu'elle soit prête pour mes vacances en juin".

Je ne suis pas d'accord. Beaucoup de clients demandent un devis pour avoir un prix FIXE. Certes, le client sera plus flexible sur les délais, mais sur le prix qu'il va payer, il te ramenera au devis que tu lui as fait. Il ne paiera pas plus, même si tu passes 2x plus de temps que prévu sur le projet.

Autre chose, ton client n'a jamais, d'un coup à l'autre, le même visage. Quand tu as affaire avec une équipe de 4 ou 5 personnes côté client, tu peux être sûr que d'une réunion à l'autre, tu n'auras pas les mêmes besoins, les mêmes visions. J'ai jamais vu une équipe, côté client, être capable de communiquer entre-elle. Alors, comment ça se gère en Agile ça ? Quand ton équipe passe 3 jours sur une fonctionnalité, qui à la prochaine réunion, devient inutile, et que tu dois recommencer le boulot. Comment tu chiffres ça en termes de budget ? D'ailleurs, je suis toujours surpris de ne voir aucune notion de budget dans les tutos Agile que je lis. On met surtout en avant le Service client. OK, mais il faut bien vivre. On va pas non plus faire des "cadeaux" au client. Parce que Agile ou pas, la production d'un projet à un coup, et on me fera pas croire que dans un mode Agile, le temps donné au projet est infini, et que le budget est fixe. Je pense que sur certain projet, ça doit coîter plus cher au client que la "gestion traditionnelle" (budget=temps).

Ensuite, je trouve qu'on vend en général mal ce concept quand on parle d'Agile: les gens ne sont pas d'un coup plus où moins compétent quand il s'agit d'estimer les coûts et délais qu'avec n'importe quelle autre méthode. Même dans le cas d'un prix fixe au forfait, les contrats sont souvent suffisamment bien ficelés pour mettre quantité de suppléments à charge du client "parce que voyez-vous, ce point n'était pas dans l'offre". Ce qui change fondamentalement c'est le choix entre rallonger le temps de dev (et donc directement le budget) et enlever des fonctionnalités.

Pour reprendre ton exemple de piscine, tu viens trouver ton entrepreneur et tu lui demandes de rajouter un système de nage parce que tu t'es découvert entre temps une nouvelle passion. Vous allez du coup devoir vous mettre d'accord pour savoir si vous rétrécissez la piscine pour gagner du budget pour la pompe et un peu de temps pour l'installer, si tu mets la main au portefeuille et que tu acceptes de ne l'avoir que mi-juin, que tu laisses tomber cette idée de nage à contre-courant, ...

Les méthodes Agile, ce serait aussi dans ce cas que l'entrepreneur dise à son équipe où creuser le trou et de la laisser gérer qui le fait, avec quels outils,... C'est de mettre en place un moyen une fois la piscine fini ce qui a bien été, ce qui a moins bien été et de capitaliser sur cette expérience pour la prochaine fois.

Les méthodes Agile nécessitent pleins d'applications et des tonnes de documentations; ou un paquet de post-it et une feuille de papier; elles nécessitent des équipes de 5 personnes pour assurer le suivi ou d'un gars un peu sensibilisé. Elles s'adaptent aux besoins (même si malheureusement, cette partie est souvent oublié par ceux qui les imposent) et sont avant tout basées sur le bon sens.

Du coup, je suis d'accord sur ce point. Agile, Scrum, cela m'a l'air d'être une mode, et c'est surtout très mal utilisé, sans doute parce que les personnes n'ont pas la marge de manœuvre nécessaire pour l'appliquer. C'est idéal dans un environnement sans pression commercial. C'est plus difficile quand le commercial te relance toutes les 5 minutes pour savoir si le projet est fini.

[gangsoleil]

Hello,

Pour répondre à ta question, je n'ai jamais vu d'équipe commerciale en Agile/Scrum/... Ça ne veut pas dire que ça n'existe pas, mais ce que j'ai vu est plutôt une équipe commerciale standard, qui fait signer un contrat avec un cahier des charges, et derrière l'équipe de développement gère comme elle veut.

Et j'ai vu cela s'appliquer entre un client "Agile" et un éditeur de logiciel "Agile"

[zecreator]

Hello,

Pour répondre à ta question, je n'ai jamais vu d'équipe commerciale en Agile/Scrum/... Ça ne veut pas dire que ça n'existe pas, mais ce que j'ai vu est plutôt une équipe commerciale standard, qui fait signer un contrat avec un cahier des charges, et derrière l'équipe de développement gère comme elle veut.

Et j'ai vu cela s'appliquer entre un client "Agile" et un éditeur de logiciel "Agile"

Oui, mais on est d'accord que ton patron va pas accepter que tu passes 50 jours sur un projet, alors que le budget n'est pas là. C'est ça que j'ai du mal à comprendre dans Agile. Comment est géré le budget, parce qu'il y en a un forcément.

Le coté, Service client, implication du client, test des fonctionnalités en cours de projet, cohésion d'équipe, c'est bien joli... Mais ça coûte combien au client tout ça ?

Par exemple, dans mon domaine du e-learning, c'est assez transparent. Un devis = un budget = un nombre de jours. Si le nombre de jours est dépassé, soit le client accepte de mettre une rallonge, soit il revoit ses besoins. Et ce système de gestion est accepté par tous les clients (c'est même impensable de démarrer un chantier sans avoir fait un devis pour déterminé un budget fixe et un nombre de jours de chantier).

Cela n'enlève rien à la qualité du Service client. Au final, le client a ce qu'il a payé en fonction des besoins qu'il a exprimé. Que cela lui convienne ou pas, c'est son problème, à partir du moment où l'on a répondu à ses besoins initiaux et que le livrable est conforme au devis initial.

Alors, je sais, ça fait un peu : "le presta est juste là pour prendre le chêque et il n'en fera pas plus que prévu...". C'est vrai. En même temps, le client est un peu un électron libre, et il change souvent d'avis, des fois à 2 jours de la livraison finale. En fait, le problème de ce type de gestion, c'est souvent parce que le client n'est jamais constant.

Du coup, pourquoi ne pas lui faire payer notre temps, si il est la cause de dépassement de budget ? On va pas bosser gratos.

[yolle]

Agile, agile .... un rapport avec des positions du Kamasutra ?. Sinon moi je pense que rien ne vaut la bonne vieille méthode qui a fait ses preuves (souvent imitée, jamais égalée) la méthode dite " A l'arrache" ... on a rien inventé de mieux en terme de réactivité. D'accord je ->.

[viper1094]

La méthode à l'arrache, oui, mais en prenant le temps de faire du code correct quand même !

[gangsoleil]

Oui, mais on est d'accord que ton patron va pas accepter que tu passes 50 jours sur un projet, alors que le budget n'est pas là. C'est ça que j'ai du mal à comprendre dans Agile. Comment est géré le budget, parce qu'il y en a un forcément.

Agile ou pas, ce que j'ai vu s'apparente à la chose suivante :

Client : Je veux une machine à café, voilà les specs
Les technico-commerciaux font une étude, et estiment ça à 50 jours de dev. Grâce à un ratio bien établi dans l'entreprise, ça te fait un devis à 75 000 euro (je dis n'importe quoi, on s'en fout). Le client négocie, bla bla, et on se met d'accord pour 60 000 euro.
Le projet arrive du coup à l'équipe technique avec comme contrainte "tu dois faire une machine à café en 50 jours"
L'équipe estime à plus de 50 jours : chacun revoit sa copie. Si c'est estimé à moins de 50 jours, on ne dit rien au client bien sûr.
On peut alors commencer les dev, et avertir le client qu'il aura sa machine dans 4 mois.
Puis, de temps en temps, on lui montre les progrès. S'il veut des modifications, pas de soucis, l'équipe commerciale est entièrement disponible pour cela ("moyennant un léger supplément on vous la fait rouge bien sûr").

[Glutinus]

Du coup, je suis d'accord sur ce point. Agile, Scrum, cela m'a l'air d'être une mode, et c'est surtout très mal utilisé, sans doute parce que les personnes n'ont pas la marge de manœuvre nécessaire pour l'appliquer. C'est idéal dans un environnement sans pression commercial. C'est plus difficile quand le commercial te relance toutes les 5 minutes pour savoir si le projet est fini.

Mais tu fais un double résumé de l'essence même du monde du travail !

Sans commercial, tout serait plus simple => bah oui, si tout tournait pas autour d'un prix à payer, les gens bosseraient sereinement, seraient plus attentifs au résultat et à la qualité du livrable. Mais la qualité est une mesure en plus du temps et de l'argent, et quand tu joues avec deux paramètres, la troisième en pâtit.

Et puis t'as beau proposer les plus belles méthodes du monde, l'être humain est ce qu'il est. Il ramène toujours à ce qu'il connaît et où il est à l'aise (et malheureusement dessert le bon sens). L'exemple que je te donnais sur les réunions hebdomadaires qui aboutissaient à rien, qui deviennent des morning-meetings "dans le bon sens" (le plus rapidement possible, on dit ce qu'on a fait la veille, on dit ce qu'on compte faire aujourd'hui, on dit ce qu'on compte faire si on est bloqué et AU BOULOT) puis qui cumulent les inconvénients des deux (des réunions stériles, et qui passent de 10 à 90 minutes, qui font perdre du temps, et QUOTIDIENNES), je l'ai vécu sur deux missions différentes.

Y avait un diagramme qui trainait y a quelques années : moins de coût, plus de qualité, c'est possible, mais c'est plus de temps. Moins de temps, plus de qualité, c'est possible, mais c'est plus cher. Moins de temps, moins cher, c'est possible, mais le résultat sera probablement bien merdique.

Pour faire une analogie avec la photo, dans un monde idéal, avec un super appareil photo, tu aurais un temps de pause quasi infini et une luminosité parfaite. Bah pour avoir fait de la photo de concert de math-rock dans des salles parisiennes à peine plus grande que quatre place de parking, je peux te dire que le cadrage, la luminosité, les pieds de micro partout, le public qui pogotte et les musikos qui bougent super vite, le travail de qualité, tu te le fous au-dessus de l'oreille (mais qu'est-ce que c'est fun de trouver des justifications de pourquoi tu peux pas faire de belles photos ! )

[zecreator]

L'équipe estime à plus de 50 jours : chacun revoit sa copie.

Et qu'est-ce qui se passe si les commerciaux ont sous-estimé le temps de production (50 jours au lieu de 60 par exemple) et que le client refuse de revenir sur ce qui a été négocié (50 jours pour 60 000€). Vous acceptez et bossez donc 10 jours gratis?

[Invité]

Pour faire une analogie avec la photo, dans un monde idéal, avec un super appareil photo, tu aurais un temps de pause quasi infini et une luminosité parfaite. Bah pour avoir fait de la photo de concert de math-rock dans des salles parisiennes à peine plus grande que quatre place de parking, je peux te dire que le cadrage, la luminosité, les pieds de micro partout, le public qui pogotte et les musikos qui bougent super vite, le travail de qualité, tu te le fous au-dessus de l'oreille (mais qu'est-ce que c'est fun de trouver des justifications de pourquoi tu peux pas faire de belles photos ! )

Pas d'accord, le bon cadrage, la bonne exposition, c'est ce que l'on recherche dans toutes les conditions de concerts ! Mais il y a aussi des conditions tellement pourries où tu ne prends pas de photos ! (pas de lumière, pas de place, conditions débiles du relationniste...)
Et j'ai commencé en argentique où si tu poussais ta pellicule à 1600 voir 3200 iso, tu le payais très cher en grain ! Maintenant, n'importe quel appareil numérique fait largement l'affaire mais ça prend toujours un bon objectif.

[el_slapper]

Et qu'est-ce qui se passe si les commerciaux ont sous-estimé le temps de production (50 jours au lieu de 60 par exemple) et que le client refuse de revenir sur ce qui a été négocié (50 jours pour 60 000€). Vous acceptez et bossez donc 10 jours gratis?

Ben, on bosse 50 jours à l'arrache, on livre un truc merdique et pas fini, et personne n'est content. Mais les commerciaux ont la satisfaction d'avoir, eux, respecté leur part du contrat : ils ont livré en 50 jours. Je suis en plein dedans(pour notre produit qui n'est pas passé en agile, mais si c'était arrivé coté agile, ça serait pareil). La grande chef a promis fin Juin "ça sera prêt début Juillet", et début Juillet, on a trouvé une grosse couille. C'est le branle-bas de combat pour livrer pas trop tard.... sauf que tout le monde va partir en vacances.

[Invité]

Y avait un diagramme qui trainait y a quelques années : moins de coût, plus de qualité, c'est possible, mais c'est plus de temps. Moins de temps, plus de qualité, c'est possible, mais c'est plus cher. Moins de temps, moins cher, c'est possible, mais le résultat sera probablement bien merdique.

Ce que tu décris ressemble au schéma suivant

[viper1094]

Pas cher et de bonne qualité, ça me semble sacrément fumeux quand même xD. Parce que plus long=plus cher.