GuieA_7 a écrit 689 commentaires

Perso, vite fait, je me dis autant allouer la memoire dans une variable statique de la fonction, et avoir un moyen de faire un appel pour liberer si necessaire.

Les variables statiques, à l'ère du multi-threading hyper courant, c'est une mauvaise idée, puisque ta fonction ne sera pas ré-entrante. Personnellement je transformerai cette fonction en une classe avec une méthode (au moins) ; l'allocation du buffer irai dans le constructeur (RAII et compagnie, et donc la désallocation dans le destructeur évidemment), et le traitement principal dans ladite méthode. Si la méthode n'est pas protégée pas un mutex (pour être un poil plus rapide), l'objet ne devrait pas être partagé par différents threads (malheureusement C++ ne permet pas de vérifier ce genre de mauvais usage à la compilation), mais au moins chaque thread peut créer/utiliser sa propre instance sans souci.

on peut pratiquement considérer qu'un logiciel non libre puisse avoir un apport au libre plus important qu'une alternative libre…

On s'éloigne encore un peu (mais tant pis c'est amusant), mais oui on peut aller jusque là si on est taquin. Un 2000ème CMS en PHP/MySQL ne sera sûrement pas une contribution majeure au libre (et ce n'est pas grave, ses créateurs font ce qu'ils veulent) ; à côté de ça, l'IHM d'iOS a beaucoup inspiré celle d'Android par exemple (ou bien 0AD est clairement inspiré d'Age of Empires etc…). Évidemment, je ne dirai pas qu'Apple, en ce qui concerne iOS en tout cas, a fait une contribution au libre, ou que c'est cool que iOS soit propriétaire. Juste qu'à leur manière ils ont apporté quelque chose à l'humanité (mais bien sûr ça serait tellllleeement mieux si c'était libre, snif).

Si je prend ton exemple de code libre en flash, peut-être bien que si, il apporte une vraie plus-value au libre, par exemple s'il s'agissait d'un logiciel de conception d'une qualité équivalente à solidworks, katia ou autocad.

Je n'ai jamais dit que le logiciel en Flash n'avait aucune plus-value. Dans mon exemple il y aurait aussi un solidworks-like libre en C++ (équivalent à l'autre en Flash), qui aurait une plus grande plus-value. Pour mesurer cette différence de plus-value libre en fonction des dépendances/technos, c'est important dans mon exemple de ne faire varier qu'un seul paramètre (la techno) ; parce que sinon comparer un solidworks en flash et un tetris en C++, n'a pas vraiment de sens.

La frontière entre le libre et le non libre est claire: un logiciel qui respecte les 4 libertés est libre, point.

Toutafé. Je suis le premier a expliquer aux gens que non, open source c'est pas juste que le code est visible ; ou que non CC-NC/ND c'est pas du tout libre.
Du coup OpenArena n'est pas libre (il se balade avec du code non libre, point), mais la version expurgée de Debian l'est.

Je ne veux surtout pas remettre en question la définition de libre ; déjà rien qu'avec la définition commune tout le monde n'est pas toujours d'accord (ex: libre selon la FSF mais pas Debian). Mais je trouve intéressant de garder à l'esprit que la liberté ce n'est pas absolue (comme tu le dis "ça dépend des sensibilités") ; par exemple, selon qu'on considère la liberté du matériel (ou qu'en fiche, parce que matériel on le change souvent, on veut juste que les spec soit publiques) on va se sentir libre ou pas.

La question est intéressante.

Je trouve qu'à l'échelle d'un logiciel, raisonner la liberté non pas de façon binaire (libre ou pas libre) mais de façon "analogique" peut être pertinent.

• soit un jeu écrit par son auteur sous Windows avec VisualC++, avec quelques scripts .bat et une interface de configuration minimale utilisant l'API Windows, le tout placé sous une licence libre. Admettons qu'on peut le porter sous Linux (et autre) en utilisant des scripts shell (à la place des .bat) et du Qt/GTK en une journée.
• soit un jeu "équivalent", placé lui aussi sous licence libre, mais écrit en Flash (et impossible à faire tourner avec les implémentations libres). Il va peut-être tourner sous Linux, mais pour les autres plateformes, il faudrait tout réécrire avec d'autres technos.

J'aurai tendance personnellement à trouver que (je rappelle que les 2 sont similaires en tant que jeu et entièrement sous licence libre) l'apport du 2ème au libre est nettement moindre ; juste dire qu'ils sont libres est un peu réducteur.

Annoncer une version stable alors même que les mécaniques de base sont visiblement remises en question (pas très amusant à jouer) ça serait une très mauvaise idée. Faire une version stable, puis faire des versions qui améliorent l'esthétique, ça c'est envisageable ; mais là c'est très différent.

C'est déjà compliqué de savoir combien de temps ça va prendre d'écrire du code quand on sait ce qu'il doit faire. Mais là il va peut être falloire des tas de tests sur le long terme pour savoir si les (futures) nouvelles mécaniques sont "amusantes". Quiconque s'intéresse au développement de jeu sait que ça signifie écrire et jeter beaucoup de code. Les développeurs peuvent bien t'annoncer que la prochaine version sera la stable, ils ne savent absolument quand elle sortira.

En plus, s'ils arrêtent de sortir des versions 'alpha', les joueurs prêts à tester, mais pas au point de vouloir compiler à la main le code du SVN, arrêteront de tester et de faire de retours (qui sont essentiels à la sortie de la version stable—donc c'est un cercle vicieux).

Donc c'est certes frustrant, mais dans la mesure où les créateurs n'ont pas un éditeur qui leur permet de travailler à plein temps et de payer des testeurs, alors lesdits tests sont faits par la communauté ; dans l'industrie classique, ces versions 'alpha' seraient internes (tu n'en entendraient même pas parler) ; en revanche il y auraient sûrement plus tard des versions 'beta' pour faire l'équilibrage final.

Évidemment il faut préciser de quoi on parle, parce qu'entre le mode solo d'un doom (suite de maps avec monstres/portes/armes) et le mode solo d'un Call of Duty (des couloirs séparés par des cinématiques :) ) c'est pas vraiment la même chose. Comme le commentaire initial parle de Half-Life (et que la dépêche est à propos d'un jeu en 3D), je suis parti de ce niveau d'exigence (donc des "cinématiques" en temps-réel assez basiques, genre un scientifique qui se fait bouffer juste quand tu arrives).

Ah oui mais concevoir des levels et concevoir des cinématiques c'est pas le même boulot !

Je ne sais pas si c'était clair mais je parle de cinématiques en temps-réel, donc qui se passent dans le niveau où tu joues, avec des modèles de personnages du jeu. Et donc oui, ça demande sûrement des compétences différentes, mais:

• si on a des outils pour le 1er "métier" et pas le 2nd, alors c'est une réponse à la question initiale.
• les gens qui arrivent à créer des campagnes solo tout seuls cumulent les 2 compétences, ce n'est pas impossible.
• même si c'est 2 personnes différentes qui font le travail, il faudra qu'elle collaborent. Pour bien faire les choses, ce n'est pas un level designer qui va faire une map dans son coin, puis un autre artiste qui va se débrouiller avec ça pour raconter quelque chose.

[…] faut coder des ia qui tiennent la route (pas faibles et pas cheatees)

Suivant le jeu que tu veux faire ce n'est pas nécessaire que les ennemis soient super intelligents ; alors que typiquement, quand les bots en multi sont idiots mais peuvent te mettre des tir à la tête avec un pistolet pourri à 300 mètres c'est énervant. Par exemple si tu combats des zombis, une IA très basique donnera un bon effet je pense.

Mais si tu dois décrire des scènes cinématiques en temps réel (tel personnage parle, tel autre intervient et la caméra va vers lui etc…) uniquement avec des lignes de code (par d'éditeur visuel), j'imagine que c'est clairement un frein.

À propos des gens qui arrive à faire des mods/jeux en étant seuls:

cela n'enlève rien au travail parfois titanesque de ces personnes, mais souvent le principe des mods consiste à réutiliser les assets du jeu solo de base (et donc on revient à mon premier commentaire sur le fait de les créer lesdits assets dans le cas des jeux libres). On a aussi les fan-games qui réutilisent de manières illicites des assets d'un jeu ; ce qui pour un jeu gratuit ne me choque pas plus que ça (quand il s'agit de toute évidence d'un hommage), mais si on veut faire les choses proprement, un jeu libre ne pourrait évidemment pas se le permettre.

Désolé je comprends bien que tu voudrais connaître l'état des outils libres permettant d'écrire des campagnes solo de FPS (par rapport à ce qu'on trouve du côté proprio) ; la question est intéressante mais je n'ai pas la réponse (si quelqu'un a la réponse, qu'il n'hésite pas). Mais en effet il est très possible que le libre soit en retard de ce côté (pas étonnant vu que ce genre d'outils est écrit à la base par des entreprises pour leurs propres besoins de campagnes solo).

Il arrive effectivement que des gens tout seul arrivent à faire des mods (voire des jeux complets) , donc c'est techniquement possible, je n'ai pas dit le contraire. Je faisais juste remarquer qu'il agit quand même d'un phénomène assez rare (la plupart des joueurs vont juste consommer), et que ramené à la population des joueurs de jeux proprios ça ne représente qu'un très faible pourcentage. Si on applique le même pourcentage à la communauté des joueurs libres (infiniment plus petite), alors ce n'est pas étonnant qu'on arrive à environ 0 ; en gros il s'agit peut-être de l'affaire d'une seule personne motivée (ou pas).

Pour faire un parallèle, on a tous les outils pour faire de la BD libre (et encore, dans l'absolu on est pas obligé de n'utiliser que des logiciels libres pour faire une BD libre). Pourtant si tu peux trouver des tas de dessinateurs en herbe qui mettent gratuitement en ligne des strips, la BD libre ça n'existe pas vraiment (sauf l'exception Pepper & Carrot). J'imagine que beaucoup de ces créateurs envisagent le jour où ils pourraient être remarqués et édités de manière classique ; et quand bien même ils connaîtraient les licences libres (ce qui n'est pas gagné), je pense qu'ils préfèrent garder le contrôle "au cas où" (et c'est triste). Du coup, autant je suis le premier à être ravi de l'existence d'outils comme Godot (qui permettent de faire des jeux plus facilement, parfois sans vraiment coder), autant il y a encore pas mal de chemin à parcourir au niveau des mentalités, car ces outils ne garantissent malheureusement pas l'arrivée de nombreuses œuvres abouties.

Pourquoi ne voit-on pas ça avec des FPS libres?

De manière générale la communauté du jeu libre est minuscule, donc des genres de jeu qui n'ont aucun représentant (un minimum abouti) il y en a des tonnes.

Après pour ta question en particulier, je dirai qu'un FPS en multi, c'est le genre de jeu vraiment très adapté à du développement itératif communautaire. Une (petite) map, une arme, une skin de joueur et tu peux déjà jouer ; ensuite les gens vont pouvoir ajouter des maps/armes/skin au fur et à mesure. Le jeu s'enrichit mais il est intéressant à chaque étape ; évidemment il faut de l'équilibrage, ce n'est pas trivial non plus, mais dans l'ensemble ça marche bien. Et détail important, les gens qui créent le jeu peuvent s'amuser au même titre que les "simples" joueurs.

Alors qu'au contraire, un FPS solo (on peut élargir le raisonnement à tout jeu centré sur l'histoire), il va falloir une map très grande (sûrement plusieurs en fait), des ennemis différents, des PNJ & beaucoup d'assets de manière générale, avant de pouvoir offrir quelque chose d'amusant au joueur. Pour une expérience aussi dense que Half-Life, il va falloir, pour chaque minute de joueur, des jours de travail pour les créateurs. Et détail important, les créateurs ne peuvent pas vraiment apprécier leur œuvre comme les simples joueurs (vu qu'il connaissent l'histoire, ce qu'il faut faire etc…).

Du coup, ce genre de jeu est vraiment plus adapté à un développement par une entreprise, qui propose une expérience à "consommer" (ce n'est pas un gros mot) en échange d'argent. Ce qui n'exclut pas que ce soit libre dans l'absolu évidemment.

Avons-nous des suites bureautiques écrites autrement qu'avec C/C++ ?

1. Une bonne partie des fonctionnalités de LibreOffice sont implémentées en Java et Python (Python remplace peu à peu Java).
2. Le moteur de rendu (en C++ donc) n'est pas IO bound, donc je ne vois pas le rapport avec ce à quoi tu réponds (à savoir: pour du IO bound, c'est grosso-modo pareil).

Tu fustiges la presse mais tu fais toi-même un bien mauvais travail d'investigation.

tous les exécutables sous Linux tournent sous l'interpréteur ELF…

ELF est un format de fichiers exécutables (ou bibliothèques dynamiques) binaire, qui sont chargés en mémoires pour être exécutés par le processeur. Pas d'interprétation là dedans.

Tu as tendance à considérer les performances comme quelque chose d'absolu (tel langage est plus performant que tel autre), mais en fait c'est plus complexe. Fortran a été pensé pour le calcul de vecteurs/matrices, et a donc une sémantique adaptée, que les compilateurs vont savoir exploiter (SIMD et compagnie) ; mais pour certaines problématiques ses qualités vont être inutiles (pas/peu de matrices/vecteurs).

Par exemple sur ce premier benchmark Fortran est premier, mais sur ce second benchmark il est derrière java/Go/C# (il est possible que le code Fortran soit mauvais, mais on devra s'en contenter si personne ne l'améliore).

C'est incroyable tout cet acharnement pour un gars qui bosse tout seul dans son coin avec un revenu dérisoire.

Le respect des licences libres (ou pas) ne dépend pas de la taille des revenus ("Ok c'est bon vous êtes une petite boite, vous pouvez violer la GPL c'est pas grave").

Et il y en a qui font la comparaison avec Redhat. Pf, n'importe quoi.

Tout à fait cette comparaison c'est n'importe quoi. RedHat ne base pas son business model sur le fait de dire que Linux c'est du caca, et qu'il faut absolument utiliser son code (mais qu'on s'efforce à ne surtout pas voir rentrer officiellement dans Linux). Non, Redhat fait plein de code libre upstream qui finit par être utilisé par tout le monde (genre gcc).

Dans le dernier exemple :

let hello name_opt => {
  let name = switch name {

est-ce que ça ne serait pas 'switch name_opt' plutôt ? (désolé si je dis des bêtises je ne parle pas le ocaml couramment)

Sinon très bonne dépêche !

Si tu multiplies le nombre de salariés par 2, la complexité/le coût de gestion peut être plus que multiplié par 2 (comme une complexité algorithmique de N² par exemple) ; quelques exemples qui me passent par la tête:

• la gestion des congés plus complexe.
• tu peux atteindre la taille où ta boite est obligée d'avoir un Comité d'Entreprise (qui a besoin d'un budget), ou de syndicats.
• à moins d'optimiser à fond (pas forcément possible selon les cas) l'utilisation de tes locaux (si tu n'utilises pas le télétravail massivement évidement), tu ne vas pas arriver à trivialement avoir 25 bureaux pour 50 personnes à mi-temps, et donc tu vas avoir besoin de plus grands locaux (le même raisonnement pour d'autres ressources est possible).
• les gens même s'ils travaillent à mi-temps vont devoir être formés pareil (ils n'ont pas une mi-formation).

Sans compter que, pour prendre un exemple avec du développement, 2 développeurs à 50% ne sont pas forcément aussi productif qu'un développeur à 100% lorsque tu dois les faire bosser sur une même grosse tâche (beaucoup de temps est perdu en communication).

Après je serais curieux de voir les résultats d'une structure mettant en place un tel système.

Ah cool donc tu vas venir présenter un logiciel Python! :)

C'est bête, avec toute l'énergie que tu gaspilles à te trigger dès qu'on parle de Python, tu pourrais coder un logiciel libre avec un "bon" langage et venir nous faire une dépêche dessus ! :)

• Pas de parenthèse pour les return.
• p.name().find(proc)!=-1 serait plus pythonique avec un simple proc in p.name()
• Si tu gardes la version 1, tu peux écrire isRunning() de manière plus pythonique là encore:

def isRunning(proc):
    pname = proc.name()
    return any(searched in pname for searched in procs)

Au final tes 2 versions se valent pour un petit script ; après si tu écris beaucoup de code, tu voudras peut-être limiter le code boiler plate. Mais ça dépend de la tête de ton code et de ton imagination.
Si tu passes ton temps à itérer sur les processus dont tu filtres le nom, tu pourrais par exemple faire un générateur:

def filtered_procs(*name_parts):
    for p in psutil.process_iter():
        pname = p.name()
        if any(name_part in pname for name_part in name_parts):
            yield p

for proc in filtered_procs('gnome', 'chrom'):
    print(p.name(), p.pid)

Et si tu veux faire du beaucoup de filtrage et selon des critères variés, tu pourrais imaginer une API qui permettrait d'écrire des choses comme (inspiration Django):

for proc in ProcessusSelector().filter(user='root').filter(Q(name__contains='gnome')|Q(name__contains='chrom')):
    print(p.name(), p.pid)

Merci pour ta réponse détaillée.

Alors, peut-être pour les projets 2D ? Hum… à voir, mais évaluez bien la concurrence avant, et surtout jetez un coup d'œil à Love2D
J'en retiens quand même quelques points positifs: pour celui qui n'a jamais utilisé un moteur de jeu accompagné de son éditeur, c'est une très bonne introduction car les possibilités étant limitées, on le prend rapidement en main.

D'un autre coté des moteurs de jeux avec éditeur associé en libre, il n'y en a pas tellement (Superpowers a l'air sympathique, pas encore pris le temps de tester). Sinon on retombe sur des love2D/Pygame/… qui sont très bien, mais qui n'offrent pas la même chose ; par exemple pouvoir régler graphiquement le timing d'une animation plutôt qu'aller dans le code modifier des valeurs dans un tableau me semble quelque chose d'appréciable (surtout s'il on a quantité de contenu, ce qui arrive dans un "vrai" jeu). Évidemment si le reste ne suit pas, le jeu peut ne pas en valoir la chandelle.

Et du coup tu as choisi un autre moteur de jeu pour faire de la 3D ?
Pour ma part quand je jouais avec de la 3D, j'aimais beaucoup Ogre3D, ne serait-ce que parce que l'exporter Blender fonctionnait bien pour des personnages avec animation par squelette (sur les autres moteurs il fallait se contenter de mesh texturés statiques). Mais de base il ne s'agit que d'un moteur 3D, donc sans éditeur, et sans binding (prototyper en C++ m'a rapidement gonflé, ce n'est pas vraiment fait pour ça). Le binding Python avait l'air pénible ne serait-ce qu'à builder (c'était y a longtemps, peut-être que ça a changé); et il y avait un éditeur en C#, mais je ne suis même pas sûr qu'il tournait sous Linux (pas testé). Si Godot arrive à fournir quelque chose de simple et fonctionnel (même si on doit se cantonner à des petits jeux) avec ses futures versions (puisque tu pointes les problèmes qu'il y a actuellement) ça serait bien.

Durant mes vacances, l'été dernier, je m'étais fixé l'objectif de tester Godot et de faire un petit jeu. Comme toujours j'ai été un peu ambitieux, j'ai juste eu le temps de faire les différents tutoriels. Mais j'ai vraiment été impressionné par la qualité du logiciel ; il semble plutôt complet (pour faire de la 2D en tout cas—la 3D est en chantier) et simple à prendre en main.

J'espère arriver à me motiver pour l'utiliser plus sérieusement (avec un petit jeu que j'ai en tête). Pour le moment je ne peux pas garantir que sur un vrai projet il n'y a pas d'écueil ; mais j'encourage tous ceux qui sont intéressés par la programmation de jeux à regarder ce projet de près.

Le dogfooding ça veut dire que les devs de Movim utilisent Movim avant tout (ils peuvent utiliser FaceBook, Twitter ou autre, ne serait-ce que pour voir ce que fait la concurrence), pas qu'ils demandent aux autres d'utiliser le même OS/environnement de fenêtres/éditeur/wallpaper qu'eux.

S'ils arrivent à faire un logiciel libre populaire (c'est tout le mal qu'on leur souhaite), leurs utilisateurs pourront migrer s'ils le veulent sous Linux (puisque Movim y est disponible aussi) ; mais le nouvel arrivant ne va pas migrer parce que ce logiciel qu'il ne connaît pas encore met Linux en premier (mais il est rassuré que sa plateforme soit mise en avant). Après il n'y a que 4 icônes, c'est pas bien grave non plus hein.

C'est tout de même désolant de reléguer Linux en dernière place

Ça me semble au contraire la moins mauvaise chose à faire que de les classer par ordre de popularité. Le jour où il y aura des paquets pour NetBSD, Haiku ou Redox, j'espère bien qu'ils seront eux aussi mis à la fin après Linux (enfin le jour où ils seront des OS plus populaires que Windows, ils auront leur place devant bien évidemment) afin de ne pas faire peur à la majorité des gens.

et de ne même pas utiliser la mascotte

Là je suis d'accord, Linux parait plus austère que les autres plateformes du coup.

Je ne sais pas si Schism Tracker compte comme ayant une interface graphique (c'est le clone libre d'un logiciel DOS nommé Impulse Tracker, et donc c'est graphique mais se manipule au clavier si j'ai bien compris), mais je l'ai vu utilisé de nombreuses fois par un streameur que je suis pour composer de la musique ChipTune (sonorité des consoles 8/16bits si vous préférez). Dans la mesure où je ne pense même pas qu'il sache c'est qu'est un logiciel libre, j'imagine que c'est bon signe signe vis-à-vis de la qualité du logiciel (ça a l'air assez rustique quand même :) ).

Je me pose des questions, peut être que des gens ici auront des réponses (je ne suis pas musicien c'est de la pure curiosité) ; il me semble qu'il faut utiliser une banque de sons (je ne sais pas comment elles se créent dans le cas du chip tune, mais pas simplement avec un microphone forcément). Si je comprends bien les musiciens amateurs vont souvent aller chercher celles des vieux jeux (NES par exemple) ; mais du coup j'imagine qu'en terme de licence ça ne doit pas être super carré (c'est toléré parce que petit/amateur), et que pour faire des musiques libres (sans aucune ambiguïté juridique) il doit falloir une banque de sons qui autorise au moins explicitement sa réutilisation, voire encore mieux une banque libre. je ne sais pas si ça existe.

Oui tout à fait (c'est le cas de Python également, même si ce qui est dans la lib standard n'est pas le mieux).

D'un autre côté, Python n'est pas non plus installé de base sous Windows (ni dans toutes les distro Linux). Si on a droit d'installer Python sous Linux, il se trouve que sous Ubuntu, reportlab est packagé aussi (donc je ne sais pas ce qui, pour l'auteur du message initial, est 'natif' là dedans). Et sous Windows l'utilisateur devrait installer Python (ou Ruby/Perl/Cygwin/…) ; et dans ce cas on doit pouvoir packager son programme, en embarquant reportlab, avec py2exe, ce qui au final revient à installer un seul programme simple également (mais ça demande un petit travail de packaging, alors que l'installeur Python pour Windows est déjà fait—mais 'pip' nécessaire pour reportlab comme tu le soulignes) ; du coup là non plus je ne sais pas ce qui est "acceptable".

Bon courage.

Ma suggestion : créer un template svg avec un utilitaire tel que inkskape […]

Autant je suis fan de Inkscape et SVG (ma page perso parle pour moi), autant je serai plutôt parti vers du PDF.

• soit générer le PDF directement avec du code, tous les langages j'imagine possèdent au moins une lib pour faire ça (ex: reportlab en Python).
• soit avoir un template Latex (c'est ce qu'on fait dans CremCRM pour les PDF des factures par exemple).

Après je ne sais pas dans quelle mesure ça serait compatible avec la contrainte assez floue "des solutions natives des 2 OS".

Ton message laisse penser que tu programmes déjà un peu ; mais au cas où ça ne serait pas le cas, je t'encourage en premier lieu à t'y essayer. Dans la mesure où c'est quelque chose de très accessible (un ordinateur, une connexion internet et zou) et où pas mal de jeunes découvrent un peu tard que leur formation ne leur plaît pas, autant savoir si ça te convient le plus tôt possible.

Si ça te plaît (ce qui est peut-être déjà le cas), je t'encourage à pratiquer ; à ton age tu as encore pas mal de temps libre normalement, et plus tard ça te servira. Il faudra quand même être capable de te remettre en question, car seul tu pourrais prendre de mauvaises habitudes de programmation ; mais avoir de l'avance sur les autres te sera utile (pas de secret, ceux qui sont bons pendant leur formation sont en général des gens qui étaient déjà passionnés avant).

Si tu en as les moyens (en terme de niveau scolaire j'entends), vise plutôt une formation BAC+5 (école d'ingénieur ou Fac) car tu auras une formation plus solide en terme de théorie ; ça peut avoir l'air barbant, mais c'est important pour vraiment comprendre ce que tu fais, et ne pas être un technicien dépassé au bout de 5 ans. Si tu préfères un BAC+2, vas en IUT ; renseigne toi, certains sont meilleurs que d'autres évidemment ; et derrière tu peux quand même changer d'avis et continuer. À l'inverse pour rentrer en école d'ingénieur, à mon avis le mieux est la prépa ; tu "souffres" pendant 2 ans, mais derrière tu as plus de choix en terme d'école, et le rythme de travail te semblera cool :)