Le 28 août 2016 nous annoncions sur ce site l’ouverture de cette formation 100 % open source, qui vise à former des développeurs d’applications modernes Web et mobiles en cinq mois de cours et cinq mois de stage. À l’époque, beaucoup de commentaires sur ce forum avaient été critiques, estimant qu’un tel projet était voué à l’échec : ce court bilan après deux promotions va démontrer le contraire et faire un appel à candidature.
La suite de l’article devrait vous convaincre…
Cette formation est assurée par un établissement public, l’ENSEEIHT/INP Toulouse, mais la moitié des formateurs sont des développeurs full stack en entreprise. Ce mélange entre professionnels et professeurs d’une école d’ingénieurs est très fructueux, conduisant à un contenu à la fois bien étayé et qui colle au plus près des besoins du marché : fondamentaux d’algorithmique en Python, programmation asynchrone en JavasSript et NodeJS, détails des protocoles HTTP et REST, UNIX et GNU/Linux et de la conception de scripts système en Python et, bien sûr, du HTML/CSS. Quand ces bases sont maitrisées, ils passent à Express, Django, DRF, VueJS, ReactJS, le tooling et l’intégration et livraison continues (CI/CD) avec webpack et GitLab, les conteneurs, la sécurité. Un travail transverse autour de l’anglais et des méthodes agiles est fait tout au long de la formation. Cinq mois de stage obligatoire en entreprise complètent et terminent l’ensemble.
Côté pédagogie, les séances sont constituées de courtes présentations suivies immédiatement d’une mise en application sur des ordinateurs portables sous GNU/Linux prêtés aux élèves. Tous les travaux à rendre utilisent le système de discussion de GitLab. La promotion est organisée en groupes de quatre et les élèves relisent leur code mutuellement. Le rythme est très intense, indispensable pour atteindre le niveau annoncé.
Côté financement, la région Occitanie va subventionner la formation pour la plupart des demandeurs d’emploi. Un job dating est organisé avec des entreprises partenaires qui proposent un dispositif de Préparation opérationnelle à l’emploi individuel (POEI).
100 % des diplômés des deux premières promotions sont au travail ! Nous augmentons le nombre de places à la prochaine rentrée d’octobre et toutes n’ont pas encore été pourvues. Car nous n’acceptons qu’une demande sur trois environ : il n’y a aucune condition de diplôme ou d’âge, mais nous évaluons le projet de chacun et lui faisons passer un petit test en Python (après lui avoir donné des ressources d’auto‐apprentissage) pour vérifier qu’il ou elle est bien fait pour ça. Nous avons ainsi refusé des bac + 5 et accepté des personnes sans diplôme, qui se sont révélées parmi les meilleurs.
Aller plus loin
- Site Web de la formation (471 clics)
- INP/ENSEEIHT formation continue (201 clics)
- Dépêche de 2017 (128 clics)
- Dépêche initiale en 2016 (111 clics)
# Ouverture des supports de la formation
Posté par Maz (site web personnel) . Évalué à 10.
Bonjour
Comment se fait-il qu'il n'y a aucun support de cours, de bibliographie, de conseils sur le site de la formation ?
Je trouve cela dommage venant d'un établissement public qui fait une formation spécialisé « open source ».
Du coup, la dépêche ressemble surtout à une publicité cachée pour une école à 5 500 € le diplôme.
En passant, il n'y a pas de modules « sécurité », c'est assez terrifiant en soit, même si je suppose que c'est intégré ici et là aux différents autres modules.
NB : Le site parle de 4 mois de stage.
[^] # Re: Ouverture des supports de la formation
Posté par buisson . Évalué à 4.
1- le site de la formation a un but de communication, pas un but pédagogique. Le partage des supports de cours est une bonne idée - il faudra voir avec les contraintes des intervenants industriels
2- la dépêche cherche effectivement à attirer de nouveaux candidats pour la rentrée d'octobre, car il nous reste 5/6 places
3- le coût réel est bien de 5500€, mais aucun candidat ne le paiera : les subventions de la région Occitanie et les POEI avec les entreprises couvriront ces frais pour tous les admis
4- il y a bien un module sécurité au programme, assuré jusque là par un spécialiste reconnu
# Formation non diplômante
Posté par _seb_ . Évalué à 5.
Sauf erreur de ma part, cette formation ne donne droit à aucun diplôme.
Un diplôme, ce n'est pas forcément un gage de qualité mais c'est déjà ça.
[^] # Re: Formation non diplômante
Posté par buisson . Évalué à 8.
Cette formation donne un DU : Diplôme Universitaire de l'Institut National Polytechnique de Toulouse.
Ce qu'elle donne surtout, c'est une formation avec le label d'une école d'ingénieurs reconnue en France. Les entreprises partenaires ne s'y trompent pas, et la grande majorité des étudiants sont embauchés dans la continuité du stage de fin de formation
[^] # Re: Formation non diplômante
Posté par _seb_ . Évalué à 2.
Au temps pour moi.
Le site web de la formation n'est pas très clair sur ce point.
# Agile... comment casser le charme!
Posté par loste . Évalué à 7.
Agile: Quelle catastrophe!
Comment saper une organisation qui marche, en reléguant les managers (y compris techniques) à du pur administratif, les spécifications à des post-it qui s'envolent comme les feuilles sans même attendre l’automne… et au final ceux qui sont rentrés dans ce truc (lécher des culs, métier d'avenir! Enfin à condition de faire le job sinon ca ne marche pas longtemps) qui sont les Iznogood (ce qu'on ne peut nier!) de l'affaire.
Certaines organisations y poussent… parce que cela permet de ne pas faire de doc! L'apothéose de la perversion d'un système qui ne demande que cela.
Bref, les seuls endroits (ou l'on fait vraiment du développement, avec de l'architecture, du matériel et du soft) ou cela fait semblant de fonctionner sont des choses simples (une IHM à faire évoluer avec le client et ses désidératas)… ou plus complexes, à condition de tricher: Arrière boutique gérée en cycle en V, vitrine pseudo agile pour les execs qui se font offrir les green fees par les peigne-culs qui poussent à cette hérésie.
Pour le reste, c'est bien de négliger les bases pour former des gens capables d'appliquer maintenant avec ce qu'ils ont appris. Mais rdv dans 20 ans.
[^] # Re: Agile... comment casser le charme!
Posté par seveso . Évalué à 3. Dernière modification le 28 juin 2018 à 08:16.
On dirait que tu as déjà eu une mauvaise expérience et maintenant te voilà devenu réticent lorsque tu entends parler d'agilité. Et ce n'est pas moi qui vais te blâmer pour ça.
Personnellement je n'ai jamais eu l'occasion de mettre en pratique de méthodes agiles mais j'avais reçu il y a bien longtemps un formation sur les techniques SCRUMM. Et le peu dont je me souviens c'est que, si on prend du recul sur le vocabulaire nouveau, en fait il s'agirait pour l'essentiel d'appliquer des mini-cycles en V sur des intervalles de temps courts, entre 2 et 6 semaines.
Et c'est loin d'être une hérésie car cela permet d'éviter l'effet tunnel : plusieurs mois de dév pour découvrir qu'en fait on avait mal compris le besoin du client et ce, malgré de magnifiques cahiers des charges et spécifications fonctionnelles.
Avec des cycles courts le client s'implique plus souvent et peut débusquer ce genre de malentendus assez tôt, ce qui limite les dégâts.
En pratique j'ai pu observer de loin de nombreux projets menés en "mode agile" et bien souvent, le choix de mode agile était surtout utilisé comme de la poudre aux yeux du client. Mais j'ai eu aussi des retours positifs de plusieurs projets donc ça me parait absurde de rejeter les méthodes agiles en bloc.
Il faut juste rester méfiant selon la personne qui emploie ces termes.
[^] # Re: Agile... comment casser le charme!
Posté par Renault (site web personnel) . Évalué à 4.
La méthode agile est très efficace pour débusquer des soucis disons mineurs. Ou éviter de prendre une mauvaise voie qui ne sera jamais corrigée. En effet une limitation dans la conception initiale difficile à corriger devrait être identifiée le plus tôt possible.
Mais cela n'est pas une méthode miracle. La méthode agile implique un minimum de spécifications à la base (ce qui est souvent passé à la trappe, car on est agile). Certains clients ou managers aussi sont convaincus que l'agilité autorise tout et n'importe quoi comme remettre en question quelque chose fondamentale dans la conception sur la fin du projet. Alors qu'en réalité ce n'est pas si simple.
Il faut comprendre que dans l'agilité, si on se rend compte que la conception de base est mauvaise (cela arrive), il faut du temps pour y remédier. Ce n'est pas au sprint suivant qu'on corrige ce genre de défauts.
[^] # Re: Agile... comment casser le charme!
Posté par claudex . Évalué à 3. Dernière modification le 28 juin 2018 à 10:43.
Ce n'est pas limité aux méthodes agiles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Agile... comment casser le charme!
Posté par Renault (site web personnel) . Évalué à 6.
Je ne dirais jamais le contraire.
Cependant j'ai déjà entendu le discours que l'agile permet de se dispenser de spécifications ce qui est bien entendu faux. Pour aucune autre méthode de gestion de projet je n'ai entendu quelque chose de similaire.
Le principal soucis de l'agile est que globalement les gens ne sont pas bien formés à cette méthode et lui font faire tout et n'importe quoi. Ce qui est évidemment un désastre si mal appliqué.
Un cycle en V a le mérite d'être mieux compris en théorie, mais a le même inconvénient d'être mal utilisé (car tout le monde trouve toujours un moyen ou une excuse pour passer outre la méthodologie).
Je dirais que globalement ce que les gens oublient, c'est que dans toute méthodologie il faut :
Sinon c'est du prototypage et donc du code jetable.
La méthodologie n'a qu'un impact sur leur mise en place dans le temps. Et sur des choses annexes (répartition des tâches, découpage des fonctionnalités, dates de livraisons, etc.).
[^] # Re: Agile... comment casser le charme!
Posté par Nodeus . Évalué à 2.
Je suis en accord avec cette analyse à 100%
avec une observation :
une correction qui coûte 1 à la conception
coûtera 100 lors de la mise en production.
[^] # Re: Agile... comment casser le charme!
Posté par Marco . Évalué à 2.
L'agile ne dispense pas de faire de la doc. Ni d'écrire des specs d'ailleurs, c'est juste qu'il y en a qui se planquent derrière l'agile pour ne rien documenter. Ce qui est vrai c'est que les specs peuvent changer en cours du projet pour s'adapter aux besoins réels de l'utilisateur.
L'agile est adapté à certains projets mais pas du tout à d'autres (et également pas du tout adapté à certaines organisations) :
Le truc c'est qu'il y a très peu de boîte qui l'applique correctement (comme tu le dis c'est une excuse pour ne produire aucun écrit). Mais quand c'est bien fait ça marche.
Par contre ça plait pas forcément aux commerciaux/managers/comptable car le coût en ressource est important : ça nécessite de voir l'utilisateur régulièrement (1 fois par semaine) pour avoir son feedback.
Ce n'est pas un mode de développement économique (du moins quand c'est bien fait),le gros avantage : si l'utilisateur lorsqu'il voit le produit évoluer voit un truc qui n'a rien à faire dans le produit final ou un oubli : comme c'est en dev la correction est rapide (contrairement à un cycle en v ou il faudrait refaire tout le cycle)
[^] # Re: Agile... comment casser le charme!
Posté par claudex . Évalué à 4.
Et donc, il faut que l'utilisateur/client soit impliqué, ce qui n'est pas toujours facile à avoir non plus.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Agile... comment casser le charme!
Posté par Renault (site web personnel) . Évalué à 4.
À mon sens on peut faire de l'agile sans le client, même si on en perd une partie de son intérêt.
Typiquement en aéronautique le cycle en V est la référence de l'industrie. Impossible d'y échapper. Mais tu peux en interne faire de l'agile par dessus pour aider à identifier les soucis de conception au plus tôt, avoir des tests globaux au fur et à mesure.
[^] # Re: Agile... comment casser le charme!
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 28 juin 2018 à 13:32.
L'agile en deux mots comme je l'ai vécu précédemment dans une grosse entreprise, au milieu de grosses équipes : si tu innoves, tu écriras nécessairement des specs merdiques parce que tu vas te tromper (personne n'est génial sur commande). Alors écris tes specs merdiques (il en faut, on est d'accord), mais n'y passe pas trop de temps dessus. Confronte rapidement à la réalité (code et tests, tests, tests, tests), et revient sur tes specs.
En faisant des boucles courtes tu :
- écris une spec qui marche
- écris un code qui marche
- teste infiniement plus
bcp plus vite, et de meilleure qualité.
Si tu es capable d'écrire d'emblée des specs d'excellente qualité (peut-etre parce que tu pars d'un existant éprouvé, que tu suis une norme, que tu as un système simple et dont tu peux intellecutellement faire le tour assez facilement), c'est peut-être pas le mieux. Mais si tu pars à l'aventure d'une manière ou d'une autre, c'est pour moi LA méthode de travail indiscutable.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Agile... comment casser le charme!
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
Créer un logiciel métier modifie le métier lui-même. Les spécifications de départ deviennent inexactes.
Le client peut demander des choses qui s'avèrent très complexes pour les informaticiens alors que des solutions plus simples et efficaces peuvent exister. Les informaticiens ne peuvent les suggérer que si ils connaissent très bien le métier.
Les méthodes agiles permettent de coller au vrai besoin des utilisateurs et non aux idées de "responsables" hiérarchiques qui sont loin du terrain.
Le cycle en V permet de vérifier qu'un logiciel est conforme aux spécifications, mais comment vérifier que les spécifications sont conformes au besoin ? Mon opinion est que le cycle en V fonctionne bien pour l'informatique embarquée où tout peut et doit être spécifié mais dès que l'on met des humains dans la boucle, il devient très peu performant.
De la même façon, l'architecture d'un système d'information est un choix critique. Si elle est bonne, le système pourra évoluer facilement. Si ce n'est pas le cas, le système vieillira très mal.
Une solution consiste à découper le projet en projets plus petits et définir les interfaces entre eux. Le responsable du projet doit être avant tout le gestionnaire de ces interfaces.
Enfin, le plus important, ce sont les compétences de ceux qui travaillent sur le projet.
[^] # Re: Agile... comment casser le charme!
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 29 juin 2018 à 07:50.
Même pas. J'ai utilisé des méthodes agiles dans l'avionique, dans la téléphonie, et maintenant dans l'automobile. Problèmes nouveaux, complexes… les specs sont à la rue dès le premier jour. En utilisant des méthodes agiles, tu rebondis plus facilement.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Agile... comment casser le charme!
Posté par Athel . Évalué à 1.
J'ai l'expérience d'un seul projet réellement en Agile, et il y a un point sur lequel je ne suis pas d'accord.
Le temps que l'on gagne d'un coté à faire des cycles courts et à aller à l'essentiel est contrebalancé par le refactoring permanent induit par ces cycles court.
Mon ressenti est que le gain des méthodes agiles est surtout au niveau de la qualité du produit (specs plus proches de la réalité, produit plus testé).
# Méthodologie de suivi du retour à l'emploi
Posté par Dario Spagnolo (site web personnel) . Évalué à 10.
Hello confrère !
Bravo pour ce beau projet dont je n'avais encore pas eu écho !
Cette partie de ton message me renvoie au sujet aussi fascinant que complexe de la mesure de l'efficacité de nos actions de formation. Et bien sûr, s'agissant de demandeurs d'emploi, de leur taux de retour à l'emploi / sorties positives.
D'abord, est-ce que 100% des stagiaires avaient bénéficié au démarrage de la formation d'une POEI avec une entreprise s'engagent à les recruter à la fin de celle-ci ?
Comment considères-tu les situations suivantes en fin de formation :
- le stagiaire trouve un emploi mais sans lien direct avec le métier visé par la formation
- le stagiaire se déclare auto-entrepreneur
- le stagiaire était en emploi avant la formation et retrouve son ancien emploi sans évolution significative en lien direct avec la formation
- le stagiaire par choix ou contrainte abandonne la formation en cours de route : est-il comptabilisé en fin de formation ?
- le stagiaire effectue un stage de fin de formation qui ne débouche ensuite pas sur un emploi
Chez O'clock nous avons une méthodologie spécifique nous permettant de mesurer le plus précisément et objectivement possible l'impact de nos formations, à travers 23 situations possibles pour les stagiaires en fin de formation.
Les cas de figure ci-dessus sont évidemment parmi les plus complexes à catégoriser et j'aurais beaucoup aimé avoir des avis, et en particulier le tien, sur ces questions.
D'un point de vue plus général, je suis dans la formation professionnelle depuis plus de 5 ans maintenant et je suis étonné à quel point il n'existe aucun mécanisme indépendant pour mesurer l'efficacité de nos formations. En gros, les taux de retour à l'emploi que nous affichons tous fièrement sur nos brochures ne sont… vérifiés par personne. DIRECCTE, Pôle Emploi, Régions, etc. Tous se basent sur des données purement déclaratives voire ne nous demandent même jamais ces infos.
Je trouve cela dérangeant en tant que citoyen car une bonne partie de nos formations sont payées avec nos impôts. Mais c'est aussi dérangeant pour les candidats à nos formations qui ne disposent d'aucun moyen de s'assurer de email de la fiabilité de nos statistiques mirobolantes…
[^] # Re: Méthodologie de suivi du retour à l'emploi
Posté par Dario Spagnolo (site web personnel) . Évalué à 3. Dernière modification le 28 juin 2018 à 08:42.
Sur la dernière phrase, il fallait lire : "Mais c'est aussi dérangeant pour les candidats à nos formations qui ne disposent d'aucun moyen de s'assurer de la fiabilité de nos statistiques mirobolantes…"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.