Stickeuse — IHM Python pour imprimante d'étiquettes Brother QL-570
Application Python/tkinter pilotant l'imprimante thermique Brother QL-570 au FabLab Les Portes Logiques, Quimper
Jérome Anamoutou (collègue BTS SIO) — tentative d'adaptation système en fin de stage #1 (piste sudo/su)
.tar.gz
Machine de Pierre et OP51 (clone zéro LogicOS) ❌ — règle udev/groupe
lp absente du master ClonezillaDéploiement sur ~20 machines prévu en Stage #3
Contexte de réalisation
Un outil pour lever une barrière technique
Le FabLab Les Portes Logiques dispose d'une imprimante thermique Brother QL-570 permettant d'imprimer des étiquettes adhésives au format DK-11208 (38×90 mm). Avant cette réalisation, l'utiliser supposait de passer par le terminal Linux et d'appeler manuellement le binaire ql570 avec les bons paramètres — une opération hors de portée pour la majorité des adhérent·es.
La mission était claire : créer une interface graphique simple, accessible à tou·tes, qui masque cette complexité technique. L'utilisateur·ice sélectionne un fichier PNG, choisit un nombre d'exemplaires, clique sur Imprimer. C'est tout.
Ce projet s'inscrit dans LogicOS 2026, une image système Debian 13/GNOME déployée sur une vingtaine de laptops du FabLab, réalisée en parallèle par Jérome A. dans le cadre de son stage BTS SIO. La Stickeuse est listée dans LogicOS sous "Logiciels de print", aux côtés du binaire ql570 qu'elle pilote.
Une contrainte technique découverte en cours de route
L'objectif initial était un déploiement sans droits administrateur. En cours de développement, j'ai découvert que l'accès au périphérique USB /dev/usb/lp0 — le fichier qui représente l'imprimante sous Linux — nécessite une configuration système préalable : une règle udev (gestionnaire de périphériques Linux) et l'ajout de l'utilisateur au groupe lp (line printer — groupe natif Linux dédié aux imprimantes).
Sans cette configuration, Linux refuse l'accès au périphérique. Le code Python est correct — c'est la configuration de la machine qui conditionne le fonctionnement. Sur l'OP42 (ma machine de stage), cette configuration a été faite manuellement, et l'application fonctionne sans aucun privilège administrateur au lancement. Sur les autres machines LogicOS, cette étape n'a pas été intégrée dans le master avant le clonage Clonezilla — c'est le chantier de Stage #3.
Cette découverte m'a permis de comprendre réellement la séparation entre le code applicatif et la configuration système sous Linux, et de formuler précisément ce qui reste à faire pour un déploiement complet.
Une illustration de la loi de Conway
Jérome Anamoutou, collègue de promotion BTS SIO, menait en parallèle le projet LogicOS 2026 — la suite logicielle à cloner sur la vingtaine de laptops du FabLab. C'est lui qui a donné ce nom à la suite. La Stickeuse était destinée à s'y intégrer sous « Logiciels de print ». Nous travaillions sur la même infrastructure, mais séparément — lui sur le master Clonezilla côté système, moi sur l'application côté code.
C'est l'avant-dernier jour du stage que Jérome a passé une heure ou deux sur mon code pour tenter de résoudre le problème de détection de l'imprimante — mais dans la mauvaise direction (sudo/su), ce qui nécessitait le mot de passe root. L'objectif d'accessibilité sans privilèges n'était pas atteint. Nous avons regretté de ne pas avoir collaboré plus tôt : si nous avions croisé nos travaux dès le début, la configuration système nécessaire à la Stickeuse aurait pu être intégrée dans le master LogicOS avant le clonage Clonezilla.
C'est précisément ce que la loi de Conway décrit : deux modules qui ne s'emboîtent pas parce que leurs développeurs ne se sont pas parlé assez tôt. La Stickeuse est le fil conducteur de mon portfolio — et cette histoire en est la démonstration la plus concrète.
La compréhension de la piste udev est venue plus tard, lors d'une conversation téléphonique pendant le week-end de l'Ascension. J'ai appelé Jérome pour savoir s'il avait exploré cette direction — la réponse était non. C'est en confrontant nos approches respectives que j'ai compris, moi-même, que c'était là que ça bloquait : la règle udev et l'ajout de l'utilisateur au groupe lp sur chaque machine. C'est le chantier du Stage #3.
Compétences E5 mobilisées
1.1 ✅ Recenser et identifier les ressources numériques
Inventorier les composants du système d'information (matériels, logiciels, données, services) et les documenter pour en assurer la traçabilité et la gestion.
Au démarrage du projet, j'ai recensé les composants de la chaîne d'impression : l'imprimante thermique Brother QL-570, le binaire C précompilé ql570 qui la pilote (dépendance non-standard, référencée sur github.com/sudomesh/ql570), et les contraintes sur les fichiers image — dimensions 996×440 px max, format 1-bit colormap. Ces éléments sont formalisés en constantes de configuration dans le code. Ce recensement a structuré le cahier des charges et conditionné les vérifications automatiques de l'application.
1.2 ✅ Exploiter des référentiels, normes et standards
S'appuyer sur des documentations officielles, des normes de qualité ou des standards techniques pour guider ses choix et garantir la conformité des solutions produites.
J'ai travaillé à partir de deux référentiels : le manuel constructeur Brother (fourni dans l'archive livrée) pour les contraintes physiques de l'imprimante, et les spécifications techniques du dépôt ql570 (github.com/sudomesh/ql570) pour les paramètres d'appel du binaire. La page wiki du FabLab sur la QL-570, rédigée par Pierre et que j'ai moi-même complétée le 09/01/2026, a servi de référence validée en contexte réel. Ces documents ont directement dicté les choix d'implémentation — format d'entrée, dimensions, chemin d'appel via subprocess.
1.3 ❌ Mettre en place et vérifier les niveaux d'habilitation
Définir et contrôler qui a accès à quoi : droits, rôles, comptes utilisateurs — de façon à protéger les ressources tout en permettant le travail des personnes autorisées.
Non mobilisée dans cette réalisation. L'application n'implique pas de gestion de comptes, rôles ou permissions utilisateurs. L'installation en root dans /opt/ est une contrainte technique, pas une gestion d'habilitation.
1.4 ❌ Vérifier les conditions de la continuité d'un service
S'assurer qu'un service peut rester disponible ou être rapidement rétabli en cas d'incident, de panne ou d'intervention technique.
Non mobilisée dans cette réalisation. La gestion des instances multiples via fcntl (présente dans une version antérieure) relève de la robustesse applicative, pas de la continuité de service au sens infrastructure — il n'y a pas de PRA (Plan de Reprise d'Activité), pas de bascule, pas de disponibilité serveur.
1.5 ❌ Gérer des sauvegardes
Mettre en place une stratégie de sauvegarde des données et des configurations, avec une procédure permettant de les restaurer en cas de perte ou de corruption.
Non mobilisée dans cette réalisation. L'archive .tar.gz est un livrable de déploiement, pas une procédure de sauvegarde.
1.6 ❌ Vérifier le respect des règles d'utilisation
Contrôler que l'usage des outils et des systèmes est conforme aux règles définies : chartes, politiques de sécurité, obligations légales (RGPD, licences, etc.).
Non mobilisée dans cette réalisation. Pas de charte, pas de politique d'usage à vérifier dans ce projet.
2.1 ❌ Collecter, suivre et orienter des demandes
Recueillir les demandes des utilisateurs, les qualifier, les prioriser et les orienter vers la bonne ressource ou procédure de traitement.
Non mobilisée dans cette réalisation. Je n'ai pas géré de tickets ni reçu/orienté des demandes. Le besoin initial du FabLab relève de l'analyse des objectifs (4.1).
2.2 ❌ Traiter des demandes concernant les services réseau et système
Diagnostiquer et résoudre des incidents ou des demandes liés à l'infrastructure : réseau, système d'exploitation, serveurs, équipements physiques.
Non mobilisée dans cette réalisation. L'installation avec droits administrateur est une contrainte de packaging, pas un incident réseau ou système.
2.3 ✅ Traiter des demandes concernant les applications
Diagnostiquer et résoudre des incidents ou des demandes liés aux applications : dysfonctionnement, anomalie, évolution fonctionnelle.
J'ai diagnostiqué un problème fonctionnel concret : le drag-and-drop initialement prévu dans le CDC ne fonctionnait pas de façon satisfaisante sous tkinter. J'ai analysé les causes, évalué les alternatives et choisi de le remplacer par un bouton « Parcourir » — solution plus robuste et plus accessible. J'ai présenté ce changement à Pierre, qui l'a validé. Cette décision est documentée dans les conversations de conception exportées. Le besoin du FabLab — permettre l'impression d'étiquettes sans passer par le terminal — est une demande applicative concrète à laquelle j'ai répondu : sélection de fichier, vérifications automatiques des contraintes image (4 critères : existence, extension PNG, dimensions via identify/ImageMagick, format 1-bit via file), messages d'erreur avec conseils GIMP intégrés, déclenchement de l'impression via le binaire ql570.
3.1 ❌ Participer à la valorisation de l'image
Contribuer à construire ou améliorer l'image de l'organisation sur le web, en tenant compte de son identité, de sa charte graphique et du cadre juridique applicable.
Non mobilisée dans cette réalisation. La Stickeuse est un outil interne de bureau — elle ne valorise pas l'image externe du FabLab.
3.2 ❌ Référencer les services en ligne
Mettre en œuvre des techniques de référencement (SEO, sitemap, structuration des URL) pour améliorer la visibilité des services en ligne dans les moteurs de recherche.
Non mobilisée dans cette réalisation. Pas de service web, pas de référencement.
3.3 ❌ Participer à l'évolution d'un site Web
Concevoir, modifier ou enrichir un site web en intégrant les données propres à l'organisation, dans le respect de ses besoins et contraintes techniques.
Non mobilisée dans cette réalisation. Application de bureau, pas de site web.
4.1 ✅ Analyser les objectifs et les modalités d'organisation d'un projet
Lire et comprendre un cahier des charges, identifier les contraintes, les acteurs et les ressources nécessaires avant de démarrer une réalisation.
Avant de coder, j'ai formalisé un cahier des charges précis : interface de sélection de fichier, sélecteur de copies, 4 vérifications automatiques des contraintes image, déclenchement via le binaire ql570, déploiement cible sur une vingtaine de machines. Ce travail d'analyse préalable — documenté dans le README et les conversations de conception exportées — a cadré tout le développement.
4.2 ✅ Planifier les activités
Découper un projet en tâches, les séquencer dans le temps et organiser leur enchaînement pour atteindre les objectifs dans les délais impartis.
J'ai structuré le projet en étapes séquentielles explicites et choisies : pseudo-code → maquette ASCII → code → tests → documentation → packaging → déploiement. Cette planification n'était pas imposée — c'est ma méthode de travail, appliquée de bout en bout et traçable dans les livrables : le dossier Label Printer - Algo et Pseudo-Code, les conversations Claude de conception, le code source, le README, le guide GIMP, l'archive .tar.gz.
4.3 ✅ Évaluer les indicateurs de suivi d'un projet et analyser les écarts
Mesurer l'avancement réel d'un projet par rapport à ce qui était prévu, identifier les écarts et les causes de blocage, et ajuster si nécessaire.
Le projet comportait un objectif précis : déployer l'application sur une vingtaine de machines LogicOS sans droits administrateur. En fin de stage, j'ai mesuré l'écart entre cet objectif et la réalité : la démo fonctionnait sur l'OP42 (ma machine de stage) ✅, mais pas sur la machine de Pierre ni sur l'OP51, le clone zéro LogicOS ❌. J'ai identifié la cause : la règle udev et l'ajout au groupe lp (line printer — groupe Linux dédié aux imprimantes) avaient été configurés manuellement sur l'OP42 mais n'avaient pas été intégrés dans le master avant le clonage Clonezilla. Cette analyse d'écart — objectif prévu vs résultat constaté, cause identifiée, action corrective planifiée en Stage #3 — est un indicateur de suivi de projet concret et documenté.
5.1 ✅ Réaliser les tests d'intégration et d'acceptation d'un service
Vérifier que les composants d'un service fonctionnent correctement ensemble et que le résultat correspond aux attentes exprimées avant mise en production.
J'ai testé l'intégration entre les différentes couches de l'application : l'IHM (Interface Homme-Machine) tkinter, les vérifications du fichier image (4 critères : existence, extension PNG, dimensions via identify/ImageMagick, format 1-bit colormap via file), et le déclenchement du binaire ql570 via subprocess. Les vérifications automatiques ont nécessité plusieurs itérations avant d'être robustes — c'est ce travail de test itératif qui les a consolidées.
5.2 ❌ Déployer un service
Installer, configurer et mettre en production un service dans son environnement réel, de façon opérationnelle et sans interruption du service existant.
Non cochée pour cette réalisation (Stage #1). Le déploiement sur le parc de ~20 machines est prévu en Stage #3. En Stage #1, l'installation a été validée sur l'OP42 uniquement. La compatibilité complète avec LogicOS — notamment la configuration udev et le groupe lp — reste à intégrer dans le master avant le prochain clonage Clonezilla.
5.3 ✅ Accompagner les utilisateurs dans la mise en place d'un service
Former, documenter ou guider les utilisateurs pour qu'ils puissent s'approprier un service et l'utiliser en autonomie.
J'ai produit une documentation utilisateur complète intégrée dans l'archive : README.md (7 sections dont dépannage en 6 sous-sections avec changelog, bugs connus et évolutions futures), GUIDE_GIMP_STICKEUSE_QL570.md (guide pas-à-pas pour préparer les images en 2 cas — adapter une image existante ou créer de zéro, sous licence CC-BY-SA-4.0), templates PNG prêts à l'emploi, manuel constructeur Brother inclus. L'objectif explicite : que les adhérent·es puissent utiliser l'outil en autonomie totale, sans assistance technique.
6.1 ✅ Mettre en place son environnement d'apprentissage personnel
Structurer les outils, méthodes et ressources qui permettent d'apprendre en faisant, de progresser de façon autonome et de capitaliser ses connaissances.
Pour ce projet j'ai dû apprendre Python/tkinter et la POO (Programmation Orientée Objet) en Python simultanément, dans un contexte professionnel réel avec deadline. J'ai organisé ma montée en compétence : phase algorithmique d'abord (schémas, pseudo-code, anticipation des écueils), lecture de la documentation officielle Python/tkinter et ImageMagick, puis utilisation de Claude.ai comme miroir critique et relecteur — jamais comme substitut au travail de fond. Les conversations exportées sont des traces concrètes de cette démarche.
6.2 ✅ Mettre en œuvre des outils et stratégies de veille informationnelle
Identifier des sources fiables, les consulter régulièrement et exploiter les informations recueillies pour rester à jour sur les évolutions technologiques et professionnelles.
J'ai conduit une recherche documentaire ciblée sur des besoins techniques identifiés : documentation officielle Python/tkinter, spécifications du dépôt ql570 (github.com/sudomesh/ql570), manuel constructeur Brother, documentation ImageMagick pour les commandes identify et file, page wiki du FabLab. Chaque source consultée a produit un choix d'implémentation concret et traçable dans le code ou la documentation.
6.3 ❌ Gérer son identité professionnelle
Construire et entretenir une présence numérique cohérente avec son parcours et ses compétences : portfolio, profil LinkedIn, livrables publics.
Non mobilisée directement dans cette réalisation. La Stickeuse nourrit le portfolio praxis-debug.net, mais ce n'est pas l'objet de la réalisation elle-même. La mise en ligne sur GitHub est prévue.
6.4 ❌ Développer son projet professionnel
Analyser ses expériences pour identifier ses points forts, ses axes de progression et les compétences à acquérir en vue d'un objectif professionnel.
Non mobilisée dans cette réalisation. Compétence à placer sur une réalisation plus explicitement réflexive.