Rejoignez Makina Corpus en tant que Chef-Cheffe de projets web junior spécialisé(e) dans les domaines du climat, de l’agriculture et de l’environnement. Intégrez une équipe engagée qui développe des solutions numériques innovantes en combinant cartographie, intelligence artificielle et analyse de données pour répondre aux enjeux environnementaux majeurs.
Vous travaillerez sur des projets qui font sens tels que la gestion d’espaces naturels et l’aménagement du territoire, en accord avec nos valeurs historiques : logiciels libres, respect de l’humain et engagement écologique. En tant que membre de notre équipe, vous participerez activement à la conception et à la coordination de projets web d’envergure, tout en bénéficiant d’un environnement de travail stimulant qui valorise la collaboration et l’innovation. Si vous êtes motivé par l’idée de contribuer à des projets ayant un impact positif sur le monde, nous serions ravis de vous accueillir chez Makina Corpus.
Vous intégrerez un pôle interdisciplinaire (chefs de projets, ergonomes, graphistes, développeurs Back/Front/Mobile, SIG, DBA…) réparti entre Toulouse, Nantes et Paris, au sein duquel vous aurez pour mission de piloter les projets de nos clients et de participer de façon active au développement commercial.
Vos missions consisteront à :
Identifier et mettre en œuvre au sein du projet les besoins technico-fonctionnels des clients ;
Formaliser, organiser, planifier et contrôler les phases de réalisation ;
Piloter et coordonner l’équipe projet ;
Assurer le suivi du planning et le contrôle de la qualité ;
Gérer les engagements vis-à-vis du client et s’assurer de sa satisfaction ;
Fidéliser, entretenir et développer le portefeuille client existant ;
Participer aux phases d’avant-vente en relation avec le client et avec nos équipes, rédiger une proposition commerciale.
Nous mettrons en place un plan de formation et un accompagnement par plusieurs chefs de projetsadapté pour vous permettre d’acquérir rapidement une très bonne connaissance de l’entreprise, son activité et son environnement, et de vous approprier et maîtriser les techniques de gestion de projet web exigeants.
Ce poste est ouvert au télétravail partiel (jusqu’à 3 jours/semaine).
Profil
Vous maîtrisez les méthodes et outils de gestion de projets web complexes et techniques, et une expérience de minimum 2 ans sur ce type de poste. Vous avez une appétence commerciale et idéalement une expérience dans la réponse à appels d’offres.
Vous aimez comprendre les besoins du client, s’approprier son métier et lui proposer des solutions adaptées ;
Vous possédez un background technique dans le développement web ;
Votre goût du travail en équipe, votre curiosité, vos excellentes qualités relationnelles seront des atouts indispensables. Apprendre toujours plus vous stimule !
Nous ne précisons pas de diplôme ou de niveau d’études minimumcar nous attachons avant tout de l’importance aux compétences et à la passion du métier.
Informations complémentaires
Dans la ruche collaborative Makina Corpus, on dit ce qu’on fait : les makiniens évoluent dans une ambiance motivante et stimulante (projets et contrib opensource, participations encouragées à des évènements/meetup, émulation entre experts passionnés, technos innovantes à tester, veille…) et contribuent aux valeurs humaines ancrées dans l’ADN de l’entreprise (environnement, équilibre vie pro/vie privée, collaboratif, télétravail…).
Mais surtout chez Makina on fait ce qu’on dit : vous avez besoin de le voir pour le croire ? Venez nous rencontrer, un.e makinien.ne pourra vous en parler ! Nos équipes sont mixtes, femmes et hommes du numérique nous vous attendons.
Écrivez-nous et racontez qui vous êtes et ce qui vous anime. Expliquez-nous en quoi vos motivations et vos compétences sont en adéquation avec nos valeurs et nos activités.
En savoir plus sur notre processus de recrutement :
Nous répondons à chacune des candidatures de manière personnalisée et dans un délai que nous essayons de rendre le plus raisonnable possible. Si votre candidature est sélectionnée, voici comment cela va se passer pour vous :
un 1° échange en visio vous sera proposé par Lise notre RRH afin de faire plus ample connaissance et de déterminer si vous, comme nous, souhaitons aller plus loin ;
il y aura ensuite un 2° entretien avec 2 chefs de projet toulousains : ce sera l’occasion de parler du poste, des missions et des projets ;
enfin, vous serez reçu.e par le responsable de l’agence.
La décision finale sera prise collectivement par vos différents interlocuteurs. Tout le long du parcours, vous serez en lien direct avec Lise.
Mesdames et Messieurs,
Je voudrais vous inviter chaleureusement à Pycon Autriche 2025.
Malheureusement, mon français n’est pas assez bon pour le reste du message, je vais donc écrire en anglais:
Please share the following message among your members:
There will be a free international Python conference in Austria from 6th to 7th April 2025: https://at.pycon.org
(conference language will be English)
Entrance is for free but registration as a visitor, volunteer or speaker is necessary. Please register now because our places are limited.
It will be a conference about the Python programming language with free entrance for visitors, free community tables for python-related groups and open-source projects and paid tables for sponsors. Among talks and workshops, there will be recruiting sessions and talks / workshops dedicated to using Python in education.
Would you be interested to represent your group with a table (or a poster / booklets / advertising material) at the conference ?
It is the goal of the conference to make it easy for visitors to connect with active people from the python community in person. It is also a goal of the conference to present to conference visitors many parts of the complex Python ecosystem of libraries and open-source projects that are connected with the Python programming language.
Also, if possible, could you please spread the message about the conference and print out and publish this poster : https://drive.google.com/drive/folders/1peXO4pThfR289gb1hpT4Elq-hVodoMtT
Bonjour
Tout nouveau, dans le monde de python, j’essaye d’exécuter un script que j’ai trouvé sur ChatGPT pouvant permettre grâce à la caméra de faire bouger la souris. Voici le script.
import cv2
import pyautogui
# Chargement du classificateur de visage
face_cascade = cv2.CascadeClassifier(cv2.data.haarcascades + 'haarcascade_frontalface_default.xml')
# Initialisation de la capture vidéo
cap = cv2.VideoCapture(0)
# Boucle principale
while True:
# Capture d'une image
ret, frame = cap.read()
if not ret:
break
# Conversion en niveaux de gris
gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
# Détection des visages
faces = face_cascade.detectMultiScale(gray, scaleFactor=1.1, minNeighbors=5)
# Pour chaque visage détecté
for (x, y, w, h) in faces:
# Calcul de la position du centre du visage
center_x = x + w // 2
center_y = y + h // 2
# Déplacement de la souris
screen_width, screen_height = pyautogui.size()
pyautogui.moveTo(center_x * screen_width / frame.shape[1], center_y * screen_height / frame.shape[0])
# Dessiner un rectangle autour du visage (pour visualiser)
cv2.rectangle(frame, (x, y), (x + w, y + h), (255, 0, 0), 2)
L’ordinateur sur lequel j’essaye d’exécuter le script est un iMac tournant sur Catalina. Lorsque je glisse le script dans ma console, j’ai le message ci-dessous.
La version python installée sur l’ordinateur est la version 2.7.16
Bonjour,
sujet certainement trivial mais je ne comprends pas la différence entre:
lab1=Label(fen1, text = "label dans fen1", bg='bisque', font=("Verdana", 10))
lab1.place(x=xl, y=yl)
et lab1=Label(fen1, text = "label dans fen1", bg='bisque', font=("Verdana", 10)).place(x=xl, y=yl)
je n’ai pas trouvé d’explication mais c’est sûr il y a une différence de fonctionnement
Dans un lien récent sur LinuxFR, j'ai défendu la simplicité de mise en oeuvre de Python par rapport à C++…du moins au moins pour un POC, ou un petit script perso. Mais quand on développe un soft un peu plus complexe, eh bien j'avoue que pour ce qui est de tout le reste, autre que le pur développement, Python perd largement de son intérêt. Ou du moins, un bon langage compilé comme C++ , (je préfère, Rust) y gagne.
Un peu d'histoire
Si l'on a vanté la portabilité de C lors de sa sortie, ce n'est pas parce qu'un programme fonctionne tel quel sur n'importe quel OS/Architecture, mais parce qu'il compile a peu près sans changement, sur toute les architectures/OS. A l'époque, on programmait beaucoup en Assembleur ou alors chaque OS avait son propre langage. En C, on avait, et c'est toujours vrai, qu'a recompiler. Et même s'il peut toujours y avoir une dépendance a l'OS (Appels système) ou à l'Architecture (Big-Endian, Little-Endian), sur un OS/Architecture, on a qu'a vérifier les PATH et librairies… et si elles manque, c'est relativement simple à rajouter. On peut même compiler avec les librairies (empaqueter) (Sauf la libC).
Les langages interprétés
Depuis les premier OS, on a eu besoin de pouvoir lancer des programmes sans paser nécéssairement, par l'étape de compilation. Le premier langage interprété "en live" est le Shell (Bash, pour les Linuxien). L'énorme avantage, pour le développeur, c'est qu'il n'y a plus de risque de segfault (Il y a d'autres risque qui y sont du coup exacerbés, mais ce n'est pas le sujet). Cependant, il introduit un problème: c'est que le programme peut être parfaitement correct mais planter si l'interpréteur n'est pas à jour ou même parfois trop récent s'il n'y a pas de rétro-compatibilité. Et ça, c'est un véritable problème a plus d'un niveau pour le déploiement.
Si ce problème existe pour tout les langage interprété, paradoxalement, c'est quand la gestion des dépendance est trop simplifié et que le langage évolue trop qu'il est exacerbé.
Bash étant quasiment immuable (on peut parfois le déplorer), on a rarement des problèmes de ce type (Mais bien d'autres ;) ).
Pour Java, on galère, souvent avec les dépendances, mais somme toute le problème est assez limité. Comme c'est assez complexe d'ajouter des librairies, on en ajoute assez peu…
Pour Python, à contrario, c'est exacerbé. Comme on a des utilitaires comme PIP, on a trop souvent beaucoup de dépendances en cascades. Évidemment, les dépendances évitent de réinventer la roue. Cependant, pour chacune on a des contraintes sur leurs dépendances, voir sur la version du langage. On peut arriver au final a devoir gérer des dépendances complexes entre dépendances.
Les environnement virtuels, permettent simplement d'éviter les conflits avec les autres dépendances installées sur l'OS, mais on garde la même version du langage.
Un cas concret: le miens
Je développe OpenHEMS, un soft en Python, car c'est simple et que je m'appuie sur Home-Assistant et qu'au départ je voulais me contenter d'un script Home-Assistant. Ce soft intègre en dépendance le code-source (Car ce n'est plus complexe autrement) d'Emhass car ce soft intègre une gestion par IA éprouvé des panneaux solaires. Évidemment, j'ai envie de disposer de la dernière version d'Emhass (pour ne pas avoir les bugs, et les meilleurs fonctionnalités). Seulement, il utilise des fonctionnalités Python 3.10 (Je ne sais plus lesquels) et je souhaites le faire tourner sur une carte Open-Hardware (conformément à ma philosophie Open-Source) : Olinuximo. Seulement, OLinuXino ne propose que Debian 11 (C'est maintenu mais pas le dernier) et avec je n'ai que Python 3.9.
Au départ, j'ai pensé recompilé Python sur l'OS et l'embarqué. Cela me permet de gérer comme je veux mes dépendances. Oui mais voilà, ce n'est pas si simple, la compilation a fonctionné, mais je ne disposait pas de toutes les fonctionnalités. J'ai laissé tombé.
J'avais aussi voulu installé Emhass avec pip, mais le problème était plus grave encore, il m'installait une très ancienne version incompatible car elle avait été mal configuré. Et ce même avec Python3.12.
Ma solution : Docker
La manière la plus simple que j'ai trouvé (et sécurisé sans trop pénaliser les performances) c'est d'utiliser Docker. Mais du coup il faut se lancer dans une compilation docker (Avec Github).
Avec Docker OpenHEMS est beaucoup plus simple tester.
C'est aussi vrai que Docker sécurise OpenHEMS. Cela évite qu'une faille OpenHEMS permette de compromettre l'OS. De ce point de vue, c'est même plus sécurisé que de le faire tourner sous un user dédié. Mais cela coupe de tous les passe droits. Quand le logiciel tourne sous docker, il ne dispose pas de tous les accès à l'OS. Or OpenHEMS utilisait certains passe-droits:
1. Il tournait en root, ce qui me permettait de lancer le VPN pour un accès maintenance. Par sécurité (vie privé et autres), je ne veux pas laisser le VPN tourner en permanence. Je veux que l'utilisateur puisse autoriser manuellement la maintenance. J'ai donc utilisé un process root, un "pseudo-cron" qui se lance avec incron quand un fichier est modifié dans un répertoire spécifique.
2. Les logs étaient directement écris dans le /var/log/openhems, il faut un montage (Mais j'ai encore des problèmes là).
En fait, on peut lancer OpenHEMS sur Python 3.9 sans docker, mais on ne disposera pas de l'option Emhass ce qui est bloquant si l'on dispose de panneaux solaires…
PS : Peut-être n'ais-je pas fait les meilleurs choix. Je suis ouvert aux réflexions en commentaires.
En langage compilé
En langage compilé, (Rust j'aimerai), j'aurais certainement codé moins vite, mais j'aurais été plus rapide sur le déploiement. Concrètement, le problème de dépendance est géré à la compilation et on l'oublie trop souvent. Cette galère que j'ai bien connu en C/C++ évite bien des tracas après.
On ne peut pas dire qu'il n'y ait plus du tout de problème de dépendances. Tout le chalenge des distributions est de géré les conflits de version des librairies dynamiques. C'est tout de même minimisé.
En Python, c'est a un tel niveau que les distributions disposent toujours de Python2 en sus de Python3 (Alors que cela date) et que maintenant, on ne peut plus installer de dépendance avec pip (sur Debian du moins). On a accès qu'aux version disponibles et gérées par les mainteneurs de la distribution.
On se moque facilement des projets js qui vont et qui viennent mais python n’est pas en reste avec ses toolchains. Pour moi qui n’utilise pas beaucoup python, je dois perpétuellement me référer à la série d’articles pour vérifier quel outil est la “bonne” façon de faire (ou en tout cas pas trop désuète) et comment l’appeler (parce que python -m pip install requests ne me vient pas du premier coup).
Et l’autre jour on m’a dit qu’il y avait un outil qui a l’air super : uv. Encore un nouveau, super. Il lave plus blanc que blanc, il rend le poil brillant, il fait revenir l’être aimé,… ? Bien sûr et pour cocher toutes les cases il est écrit en rust.
Bon il s’avère que j’étais sur un petit outil en python donc essayons la doc d’installation :
curl -LsSf https://astral.sh/uv/install.sh | sh
(Quand je vais leur raconter ça sur linuxfr, faudra que ce soit un vendredi.)
Et l’usage ?
créer un projet ? uv init dossier
ajouter une dépendance ? uv add ma-super-bibliothèque
lancer mon projet ? uv run mon-script.py
Ok c’est rapide ça utilise un environnement virtuel, ça m’a créé quelques fichiers
pyproject.toml
uv.lock
.env/
.python-version
Ouai je vois bien à quoi sert chaque fichier.
Au final pour mon usage simple ça fait le job très bien. Je ne sais pas s’il peut servir à créer des wheel comme il faut etc, mais pour ce que je fais de python il a l’air simple et efficace. Il installe les dépendances plus vite que pip et les commandes sont simples à mémoriser.
Marco 'Lubber' Wienkoop pour son travail sur Fomantic-UI, un chouette framework CSS que nous utilisons dans canaille. Fomantic-UI est aussi utilisé par d'autres outils sur lesquels nous comptons, comme Forgejo.
Hsiaoming Yang pour son travail sur authlib, une bibliothèque python d'authentification que nous utilisons dans canaille.
