Bonjour à tous,

je souhaiterais mettre en place cette solution au sein de mon entreprise afin d'améliorer la gestion des tous nos équipements informatique.

J'aimerais savoir s'il serait possible de scanner un code barre collé sur un équipement et que la base de donnée nous remonte les infos suivantes :
emplacement, date du transfert, propriétaire etc par exemple ?

Merci d'avance de vos réponses,

Bien cordialement,

Alexis

Bonjour Alexis,
C'est une bonne idée, à laquelle on a récemment pensé mais pas encore noté ici. Merci du coup !
Dans l'absolu, c'est tout à fait faisable (dans la prochaine version du Robert en tout cas).

Le problème se décompose en plusieurs parties :

1. Création d'une image-code imprimable qui est lié à un matériel ou un pack de matériel :
   • Code barre "à l'ancienne" ou bien QRcode ?
   • Quelle(s) librairie(s) de génération graphique utiliser, et dans quel langage (php, python, ...) ?
   • Quelle est la liste exacte des informations à lier à un code-barre ?
2. Lecture du code barre ou QRcode avec un appareil relié à un système qui a accès à l'API du Robert :
   • Si c'est une scanneuse reliée en USB à un ordinateur, il faut créer un logiciel (multi-plateforme) qui sait utiliser la scanneuse, et qui communique avec l'API du Robert via le web pour récupérer ou mettre à jour les infos
   • Si c'est un QRcode, on peut créer une application smartphone ou tablette qui, reliée à internet, pourra utiliser l'API. Cette dernière solution a un côté pratique car tout détenteur d'un smartphone relié à internet pourra l'utiliser, même ailleurs que dans les locaux.
3. Utilisation d'un API Robert pour la lecture des codes. Pour créer cet API il nous faudra lister tout les cas d'utilisation type que l'on pourra rencontrer :
   • Récupérer les informations d'un matériel ou d'un pack de matériel en scannant le code (contenu du fly, prochaines locations prévues, prix total, etc)
   • Définir des informations pour un matériel ou un pack de matériel en scannant le code, puis en cliquant sur un bouton d'action, comme par ex. "Livré", "Retour OK", "Incomplet", "Panne", etc.
4. La sécurité :
   • Comment on connecte un utilisateur à l'API via l'application dédiée ?
   • Qui a accès a quoi dans l'API (ACL, niveaux d'habilitation) ?

N'hésitez pas à lister tout les cas d'utilisation que vous imaginez ici sur le forum.

Le développement de la prochaine version du Robert (2.0) ne commencera qu'une fois que les fonds nécessaires seront réunis, c'est à dire pas avant le mois d'avril 2016. Ce qui nous laisse le temps de penser à tout !
Cheers,
.Polo

Bonjour Polo,

Tout d'abord je vous remercie de ta réponse rapide. Concernant le scan je pense aussi qu'un QRcode serait nettement plus pratique pour ma société, d'autant plus qu'elle serait plus réaliste au vu du monde connecté dans lequel nous vivons.

Pour ma part la liste des informations liés au QRcode serait celle-ci :
Numéro de série ; état fonctionnel ou pas ; modèle ; @Mac ; fournisseur ; date de référencement ; date d'acquisition ; garantie ; OS.
Toutes ces infos auront été recensées en amont évidemment.

Concernant les problèmes auxquels nous seront confrontés et que vous avez pris le soin de détailler, je souhaiterais d'abord vous poser deux questions :
Quels logiciels libres de gestion de matériel vous ont inspiré afin de développé robert ?
Et dans le meilleur des cas, auraient déjà implémenté la fonction scan ? (si existant)

Je vous remercie de prendre la peine de me répondre et attends avec impatience une réponse de votre part.

Bonne journée !

Alexis

Réponse rapide : Aucun

À ma connaissance, aucun logiciel libre ne proposait les fonctions que l'on a développé pour Robert. Nous avons pensé le logiciel à la base pour la location de matériel son/lumière, à partir de "zéro", c'est à dire sans inspiration d'aucun autre logiciel, juste avec notre expérience et nos besoins en terme d'outils d'organisation.

Merci pour vos idées, retours d'expérience, etc. qui seront précieux lors de l'écriture du cahier des charges du Robert 2.0 !

Bonjour,

Je serais aussi grandement intéressé par l'intégration de la possibilité de scanner des équipements (pour le suivi individuel, la gestion des retours et des stocks, etc).

Par contre pourquoi limiter entre les codes barres ou les QR codes ? Ne serait-il pas possible d'autoriser les 2 ?
De notre côté, on opterait plutôt pour des codes barres. L'avantage du code barre c'est que c'est juste un nombre, qui peut toujours être entré à la main si jamais on n'a pas la douchette avec nous, alors qu'un QR code est illisible tel quel.
Par ailleurs les codes barres sont très faciles à utiliser, pas besoin de créer un logiciel pour ça, en fait les douchettes USB envoient en input les caractères du code barre comme si on les avait entrés sur un clavier. Il suffit juste que le bon champ du formulaire ait le focus.

Merci pour tout ce travail, et bon courage.

@fbastien D'accord et concernant la partie scanner, le QRcode se démarque selon moi du code barre par son interopérabilité, en effet un smartphone peut maintenant scanner un QRcode. Après c'est sur si on a ni scanner ni smartphone à dispo, le bon vieux code barre semble plus pratique.

Mais je pars du principe que nous avons "tous" un smartphone sur soi en permanence, donc pas la peine d'avoir de code barre.

@polosson

Il est vrai que c'est une bonne initiative d'avoir développé cet outil qu'est Robert, d'autant plus que vous travaillez en fonction des dons, c'est donc important de le souligner.
En revanche, le fait qu'il se base essentiellement sur la location de matériel (son\lumière) ne me concerne pas vraiment suivant mes besoins perso.
Cependant la fonctionnalité de scan ouvre énormément de possibilités et gain de temps. Ce n'est pas une chose à négliger.
Je vais maintenant en profiter pour faire appel à vos connaissances en vous demandant : connaîtriez-vous un logiciel (libre ou pas) permettant la gestion de stock avec la fonction scan. Je suis persuadé qu'il existe des solutions de ce type utilisées par des sociétés.

Merci à vous deux

Il est bien entendu possible d'intégrer les deux solutions : QRcode et code-barres. À voir si on peut intégrer les deux côte à côte dans l'interface, et choisir lequel afficher lors de sa création, ou bien si c'est un paramètre de préférences ou configuration du Robert dans sa globalité pour n'utiliser qu'un seul des deux dans l'interface.

Voici deux librairies (jQuery & PHP) qui pourront être utilisées pour la génération :

• barcode-coder pour les code-barres standard
• PHP-QRcode pour les QR codes

@fbastien effectivement il n'y a pas besoin de créer un logiciel spécifique quand on utilise une douchette USB. Par contre pour les QRcodes je pense qu'il faudra quand même créer une appli (smartphones ou tablettes) qui fera le lien... À moins qu'il soit possible de faire la même chose qu'avec les douchettes (focus sur un input dans un navigateur, et prise de photo du QR code via une appli existante) ?

Merci pour vos retours, ++ !

PS, @fbastien as-tu reçu mon message perso que je t'ai envoyé via le forum ? Si non, peux-tu me donner ton adresse email en me contactant depuis mon site-web perso STP ? Merci, cheers !

@alexishermel

En revanche, le fait qu'il se base essentiellement sur la location de matériel (son\lumière) ne me concerne pas vraiment suivant mes besoins perso.

Oui, cette version du Robert est très spécifique au matériel de spectacle, car c'est l'activité principale des initiateurs du projet En revanche le Robert 2.0 sera beaucoup plus "souple" quant à la nature des matériels (catégories modifiables, tags, etc.)

Je ne connais malheureusement pas de logiciel de ce type avec gestion de code-barres, même si je pense que ça doit effectivement exister.

Cheers !

@alexishermel

Ma remarque n'était pas pour dire non aux QR codes, mais seulement que les codes barres pouvaient aussi servir, et que c'était dommage de s'en priver surtout qu'ils sont très faciles à mettre en place techniquement au niveau du logiciel, contrairement aux QR codes.
Après il y a effectivement la question de comment gérer la cohabitation des 2 ou leur paramétrage, mais ça me semble faisable facilement et ça vaut le coup à mon avis.
Merci pour la suggestion cela dit.

@polosson

@fbastien effectivement il n'y a pas besoin de créer un logiciel spécifique quand on utilise une douchette USB. Par contre pour les QRcodes je pense qu'il faudra quand même créer une appli (smartphones ou tablettes) qui fera le lien... À moins qu'il soit possible de faire la même chose qu'avec les douchettes (focus sur un input dans un navigateur, et prise de photo du QR code via une appli existante) ?

Je t'avoue que je n'y connais quasiment rien sur l'implémentation technique des QR codes, et ça dépend aussi quel type de données tu mets dessus (juste un identifiant, l'URL d'une API à appeler, etc.). Mais effectivement au premier abord, j'ai l'impression que ça nécessite un peu de dev pour s'intégrer correctement.

PS, @fbastien as-tu reçu mon message perso que je t'ai envoyé via le forum ? Si non, peux-tu me donner ton adresse email en me contactant depuis mon site-web perso STP ? Merci, cheers !

Je n'ai pas reçu de notification pour ton message (ça se configure ?), mais maintenant je t'ai répondu

Hello à tous !

@alexishermel: intéressants messages qui contiennent des idées de données que tu souhaites voir pour le matériel. Il me semble que dans la première version, on avait une page 'développeur' qui permettait d'ajouter des champs dans les base de donnée par les utilisateurs (par ex. dans la gestion des utilisateurs un admin du Robert peut ajouter un champs 'couleur des yeux' sur sa version du Robert sans entrer dans le code du programme).

code barre 1d ou 2d ? : concernant le choix QR ( code 2 dimensions ) / code barre 'classique' ( code 1 dimension ), il existe des douchettes qui lisent les 2. Je pense que le plus simple/souple : créer une étiquette à imprimer qui contient les 2 codes

• Le premier en QR contient l'adresse du site et l'ID matos en paramètre ( adapté smartphone )
• Le second 1D contient seulement l'ID matos, et permet de renseigner un input avec une douchette standard et peu coûteuse. ( configuration poste fixe, à l'entrée du point de stockage du matos ).

Sláinte.
Moutew

Salut,

Pour préciser ma pensée : en fait en ce qui nous concerne (ça reste peut-être un cas particulier), nous ne comptons pas imprimer nous-même les codes barres, mais acheter des rouleaux pré-imprimés.
Après je suis d'accord que c'est mieux de permettre l'impression des 2 types. Si la taille des étiquettes reste correcte, pourquoi pas les 2 ensemble effectivement.

Cela dit, le point le plus compliqué côté software n'est pas d'imprimer les codes, mais d'intégrer le lecteur de codes et de gérer les actions derrière (simple consultation, check list retour/inventaire, etc.).

Bonjour à tous !

@fbastien

La cohabitation des deux codes désignés précédemment serait en effet utile car elle permet une certaine redondance. En revanche la question que je me posais c'est que ça sous-entends deux paramétrages différents donc un appel à deux bases de données ?

@Moutew

La personnalisation des champs dans les bases de données est pour moi essentielle pour ce type de logiciel et permet aussi de suivre l'évolution de la gestion de son stock ( par l'arrivée de nouveaux types de matériaux par exemple).
Cela dit : bonne idée l'étiquette contenant les deux types de codes barre.

@polosson
J'ai vu que vous étiez déjà en train de choisir le logo du prochain robert, peux-t-on savoir quelles fonctionnalités seront disponible dans la prochaine version ou c'est encore un secret ?
Bon courage à l'équipe pour la suite.

A très bientôt tout le monde !

Alexis

@fbastien : peux tu nous dire ce que contiennent ces rouleaux de codes barres ? une suite numérique ? Dans ce cas cela impliquerait une admin qui crée le lien entre un matériel et un code barre déjà défini. Lien qui dans ma compréhension du système se ferait à la main. Dans le cas où le programme génère les CB, ce lien serait automatique.

Concernant le software j'ai réalisé un système similaire grâce à des CB alphanumériques

• On scanne l'ID d'un item ( CB = "ID:123654-65445" )
• On scanne l'action ( CB = "QTE:1" ) sur une référence qui contient tous les CB des actions.

Cela qui permet de ne pas lâcher la douchette de la main pour contrôler le prog.

@alexishermel

La cohabitation des deux codes désignés précédemment serait en effet utile car elle permet une certaine redondance. En revanche la question que je me posais c'est que ça sous-entends deux paramétrages différents donc un appel à deux bases de données ?

Je te rassure de ce côté-là, ça ne pose aucun soucis de base de données, au "pire" c'est juste un champ supplémentaire dans une table, mais en aucun cas ça nécessite de séparer en 2 bases de données.
Après, selon ce qui est décidé, il faut voir si les 2 cohabitent ensemble sur l'interface ou s'il faut mettre un paramétrage pour que chacun choisisse lequel des 2 utiliser.

@Moutew

peux tu nous dire ce que contiennent ces rouleaux de codes barres ? une suite numérique ? Dans ce cas cela impliquerait une admin qui crée le lien entre un matériel et un code barre déjà défini. Lien qui dans ma compréhension du système se ferait à la main. Dans le cas où le programme génère les CB, ce lien serait automatique.

Effectivement, c'est une suite numérique, et c'est dans l'idée de les entrer à la main dans le système. Cela dit, ça revient à peu près au même puisque si c'est le soft génère les CB, tu dois faire attention de bien coller le CB qui correspond au matos ; alors que moi je peux juste coller tous les CB au hasard, et après je les scanne pour les entrer dans le logiciel.
De toute façon, pour l'instant notre parc de matos n'est pas encore enregistré dans Robert, donc de toute façon j'ai du travail de saisie. D'ailleurs pour gagner du temps, je vais peut-être plutôt essayer de saisir les données dans un tableau Excel et après utiliser un petit script pour les insérer dans la base de données.
Peut-être que c'est une chose à penser pour la nouvelle version : comment insérer des données en masse lors du premier inventaire ou d'un renouvellement de stock, sans avoir à recharger des pages pour chaque article ?

Concernant le software j'ai réalisé un système similaire grâce à des CB alphanumériques

• On scanne l'ID d'un item ( CB = "ID:123654-65445" )
• On scanne l'action ( CB = "QTE:1" ) sur une référence qui contient tous les CB des actions.

Cela qui permet de ne pas lâcher la douchette de la main pour contrôler le prog.

Ah c'est une bonne idée le coup des codes barres pour les actions !

Par contre, en y repensant, il faut bien prévoir la possibilité de gérer le matériel avec et sans codes identifiants.
Bien sûr il y a ceux qui ne veulent pas en utiliser qui doivent pouvoir gérer leur matériel sur le logiciel comme c'est le cas actuellement. Mais même pour quelqu'un qui utilise des codes, il n'en met pas forcément sur chaque matériel (ex : consommables, câbles, etc) ; et dans une même liste on pourra avoir à la fois des items identifiés individuellement par code, et des items où on indique juste leur nombre (fonctionnement actuel).

@alexishermel : Le Robert est open-source, absolument rien n'est secret, c'est juste que pour le moment les fonctionnalités de la prochaine version n'ont pas encore été "compilées" en un cahier des charges précis... C'est le but de ce forum, regrouper les idées de chacun pour y voir plus clair et faire quelque chose de bien pensé dès le départ pour s'adapter à un maximum de situations.

@fbastien bien d'accord, il faut pouvoir avoir le choix d'utiliser les code-barres ou pas ! Je serais même d'avis d'intégrer cette fonctionnalité en mode "plugin", c'est à dire comme une librairie qui s'intègre à l'interface si elle est activée... Mais cela suppose une structure globale bien pensée, un coeur en béton et une gestion d'erreurs pratique ! En tout cas on avait pensé à faire un système de plugins, afin de pouvoir étendre les fonctionnalités de manière "simple" pour les dev qui ont des besoins spécifiques... Il faudra bien se pencher sur l'histoire, mais je pense que c'est faisable !
Et, bien d'accord aussi, outre l'activation de ce plugin, le fait qu'il soit facultatif dans le fonctionnement est essentiel (matériels avec ou sans code-barre associé).

@Moutew yes, bien vu les code-barres d'action, faut juste pas s'emmeler les pinceaux entre les 2 types lol

@polosson
Les plugins c'est une bonne idée, mais faut voir selon le temps dispo car ça risque de prendre pas mal de temps à implémenter. Je m'y connais pas trop en intégration de plugins, mais j'imagine qu'il faut faire une API bien ficelée.
Après c'est sûr que c'est plus facile en repartant de l'appli à zéro car on peut y penser dès le début et organiser le code en conséquence...