Merci pour ce long commentaire. Je ne vais pas réagir sur tout mais sur 3 points principaux.
Rappel du contexte : je gère une entreprise indépendante qui produit et déploie des logiciels libres. L'aspect « indépendant » de l'entreprise est fondamental dans ma vision car chaque euro dépensé est un euro qui sort de notre trésorerie, chaque euro dépensé pour des travaux non prioritaire est un euro investi avec un retour sur investissement imprévisible.
Les ingénieurs veulent souvent « faire bien » et malheureusement même « faire mieux » . Plus facile à maintenir. Mieux conçu. Plus robuste. Mieux testé. D'ailleurs ça vaut pour les autres métiers : une personne de la comm' voudra « toujours faire un peu plus ». Un peu mieux mis en page. Des goodies un peu plus sympas. Un design un peu plus esthétique. Des vidéos un peu mieux montées.
De la manière dont tu formule les choses, c'est comme si il y avait un "bien" qui soit absolu, connu et visible de tous, et que certains voudraient faire mieux.
Est-ce qu'ils veulent faire mieux, ou est-ce que leur vision de ce qui est bien est différente ?
Plus généralement, comment on sait quand c'est bien ?
Je prends un exemple simple : dans le contexte que j'évoque, nous travaillons sur un projet de développement commandé par un client. Dans ce cas, le bien est « simple » : c'est quand ça répond au projet et au cahier des charges signés entre l'entreprise et le client. Ni plus, ni moins :
moins, : ça ne répond pas au contrat
plus : c'est de l'argent que Algoo dépense en plus pour des bénéfices dont seul le client bénéficiera. C'est de la sur-qualité (le fameux « le mieux est l'ennemi du bien »)
Ta logique me semble inscrite dans une logique capitaliste et libérale.
Ce n'est ni du libéralisme, ni du capitalisme : c'est de la gestion de rentabilité.
C'est le nerf de la guerre d'une entreprise, y compris une SCOP.
Mais le besoin (de l'entreprise) n'est pas de faire mieux. Son besoin est de faire bien, juste bien.
Quelle place pour les besoins des employés ?
Pour s'occuper correctement des besoins des employés, une entreprise doit déjà être correctement rentable.
Pour être plus/mieux rentable il y a deux leviers :
augmenter les prix (à travail équivalent) ou augmenter les ventes (si le travail n'est pas linéaire
optimiser les dépenses (plusieurs options : minimiser les salaires, réduire les travaux inutiles, factoriser/mutualiser les travaux de développement, réduire les coûts de maintenance, etc, etc)
Dans mon parcours de chef d'entreprise (depuis plus de 10 ans maintenant), les plus militants pour « faire les choses à l'état de l'art sans dette » étaient paradoxalement les plus exigeants sur le sujet des besoins individuels des employés.
Les travaux qui ont apporté le plus de valeur à mon sens (valeur = bénéfices vs coût) :
ceux sur lesquels on a travaillé proprement tant sur le plan de l'architecture que du développement - par exemple l'architecture temps réel de Tracim avec ses API REST et son mécanisme d'événements et messages envoyés via un socket à chaque client. On n'a pas accumulé de dette sur ce sujet, on l'a fait correctement dès le départ. C'était une brique structurante, je savais exactement ce que je voulais qu'on fasse (et aujourd'hui, personne ne fait aussi en ingénierie sur des applications web à ma connaissance)
ceux qu'on a développé en mode POC en très peu de temps. La fonctionnalité de Kanban de Tracim par exemple, ou encore des outils internes de gestion reposant sur du dev « à l'arrache » sur base d'applications web Django.
ceux qu'on a fait sans respecter l'état de l'art car ils ont permis d'industrialiser très rapidement puis d'améliorer progressivement : scripts bash ou python « bricolés », conteneurs docker utilisés « comme des VM ».
Dans ces exemples, à part pour la partie architecture, il y a de la dette. Et pour la partie architecture, en réalité Tracim avait déjà 5 ans d'existence - donc des lacunes et des évolutions voulues bien identifiées.
La dette permet d'arriver « en avance » sur le marché par rapport aux moyens financiers qu'on a. Ça permet de signer avec des clients qu'on aurait loupé sans cela. Ça rembourse le surcoût lié à l'endettement (car au final les travaux de refonte coûtent)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
J’en suis parti et ai appris quelques mois plus tard qu’ils ont perdu les gros clients (qui avaient certainement/probablement marre de payer des correctifs abscons…)
En plus de 10 ans de boîte, je n'ai jamais eu de client qui parte car on avait trop de dette technique. Parce que c'est trop cher, parce que ça répond mal oui, mais pas parce qu'il y a trop de dette technique.
En revanche, des clients qui ne viennent pas parce qu'il manque une fonctionnalité, oui. Et pour réussir à les signer quand même, il n'y a rien de mieux qu'une fonctionnalité « ajoutée à l'arrache » et qui est retravaillée en parallèle de la signature du client ou de la mise en place.
Mais pour être capable de faire ça, il faut des développeurs qui comprennent l'enjeu et sont pro-actif dans cette stratégie de dette.
Ça ne veut pas dire saloper le travail, ça veut dire livrer vite même si un peu moche avec l'idée de rectifier / améliorer ensuite.
Certains vont me dire « oui on sait ce que ça donne ensuite ça passe sous le tapis » . Possible : si ça marche bien il n'y a pas de raison de retravailler la fonctionnalité (ou pas tout de suite).
En revanche, le prospect que tu n'as pas signé, tu as aucune chance de le voir revenir.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Mon postulat est que rien n'est mal fait : c'est fait avec les moyens, les objectifs et la compréhension du moment. Et c'est donc de la dette si après coup ça semble inadapté ou mal fait.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
mais plutôt entre «trop vite et mal fait pour satisfaire le market» et «d'un standard suffisant pour ne pas grèver l'avenir»
La dette n'est pas un travail bâclé : la dette c'est emprunter du temps de développement à venir pour livrer plus rapidement une première version (ou des premières versions).
Et c'est précisément pour satisfaire le marché - parfois juste pour être le premier.
J'ai vécu dans une boite entièrement pilotée par le commerce, et effectivement il a fallu chiffrer cette dette en numéraire (en temps perdu par les développeurs, en allongement de délais) pour obtenir du temps pour la combler au fil de l'eau.
Si la langue de ton management c'est des montants en euros, il est naturel de convertir ta vision technique en euros : c'est la meilleure manière de les convaincre.
Si ton management sait qu'il s'est endetté, il sait aussi (normalement) qu'il faut qu'il rembourse pour pouvoir de nouveau emprunter lorsqu'il en aura besoin.
La dette n'est pas du travail mal fait. La dette, c'est du travail court-terme (ou moyen-terme) qui a vocation à être remboursé ; et comme une dette financière, tu rembourses + que ce que tu as emprunté. En revanche, ce surcoût est censé t'avoir permis de gagner plus - donc le calcul au final est positif, même une fois que tu as terminé de rembourser.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Ça parle longuement de dette technique. Puis vient ceci :
Unless leadership has an engineering background, the value of the technical debt work likely needs to be quantified and shown as business value.
La réalité, dans une boîte, c'est que la dette technique doit être vue et évaluée par sa valeur « business » et uniquement cela. Peu importe que le management ait des compétences techniques.
Les ingénieurs veulent souvent « faire bien » et malheureusement même « faire mieux » . Plus facile à maintenir. Mieux conçu. Plus robuste. Mieux testé. D'ailleurs ça vaut pour les autres métiers : une personne de la comm' voudra « toujours faire un peu plus ». Un peu mieux mis en page. Des goodies un peu plus sympas. Un design un peu plus esthétique. Des vidéos un peu mieux montées.
Mais le besoin (de l'entreprise) n'est pas de faire mieux. Son besoin est de faire bien, juste bien.
Et s'il y a du temps dispo, documenter, industrialiser et normaliser pour que la prochaine fois, ce soit mieux.
Sur le fond du sujet, je suis relativement d'accord : les problèmes techniques sont en fait des problèmes humains qui sont en fait des problèmes de désalignement entreprise/collaborateur.
Est-ce que l'entreprise a tord d'être complaisante ? Est-ce que l'ingénieur a raison de vouloir éviter la dette technique à tout prix ? Ce qui me semble important, c'est surtout d'évoluer (en tant que personne) dans un écosystème (entreprise, marché) dont on partage les valeurs.
Et ça, ça veut dire se renseigner et s'ouvrir aux considérations non techniques.
Sans cet intérêt, sans cette ouverture, c'est perdu d'avance.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je ne connaissais pas LSP. Est-ce un protocole largement utilisé ? Si je regarde le repo github de LanguageTool et plus précisément celui de languagetool-languageserver, visiblement le support de LSP n'a pas bougé depuis 4 ans.
Quelqu'un ici aurait un retour d'expérience / des infos sur le sujet ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Comme indiqué dans le journal, nous allons reprendre le projet et pour cela il va y avoir du pain sur la planche.
Comme discuté par ailleurs, il y a les aspects purement techniques — pas d'inquiétude de mon côté de ce point de vue ; mais il y a aussi les aspects « produit » et langue française à reprendre ; et peut-être l'aspect communautaire à réamorcer.
Nous allons communiquer officiellement début janvier sur la reprise du projet — plan d'action, roadmap et probable campagne de financement participatif (pour laquelle nous solliciterons les contributions individuelles mais aussi et surtout institutionnelles).
En tout cas, sacré boulot Olivier pour cette nouvelle version (et pour les précédentes) - je ne m'attendais pas à un contenu aussi riche. Ça n'a pas dû être de tout repo de reprendre le projet après sa phase de sommeil … et merci pour toutes les explications que tu m'as données en privé.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
pour moi c'est clair que postmarketos est l'union des nerds qui fait la force, quand à coté sailifish/jolla regardent pas vraiment dans la bonne direction..
Sailfish semble avoir une cible d'usages plus variée que 100% mobile.
Les os "installés à la main" sur un mobile acheté par ailleurs, j'ai essayé, ça a marché mais c'est de l'énergie que je préfère mettre ailleurs aujourd'hui.
L'histoire racontée par Jolla me parle plus que Fairphone (dont le marketing a l'air bien "à l'américaine").
Ça m'a l'air d'être la seule alternative pour sortir du duopole Android/ios sans nécessiter des heures de bidouille.
C'est européen.
Jolla donne l'impression d'être une boîte pérenne économiquement (c'est complètement subjectif, c'est basé sur un marketing sobre - ils en font pas des caisses, et ils sont présents dans d'autres activités que le téléphone mobile).
J'ai un peu hésité personnellement pour 2 raisons :
Le poids
Le nombre de ports
Je suis finalement resté sur mon choix de cœur historique : la gamme Portégé.
Historiquement c'était Toshiba, aujourd'hui c'est Dynabook.
C'est pas vraiment réparable (la RAM est soudée - c'est LE point problématique), c'est pas conçu pour être évolutif, c'est vendu avec Windows, et désormais c'est clavier QWERTY uniquement.
Mais c'est hyper léger (moins de 1kg pour un 13 pouces) , boîtier en magnésium hyper résistant et "pas mou", il y a un max de ports.
C'est pas distribué officiellement en Europe, il faut passer par des moyens détournés pour en acheter.
J'ai pas trouvé d'alternative avec autant de ports sur les petits formats - je suis intéressé si vous en connaissez (je parle de gamme "pro", budget en conséquence entre 1500 et 2000€ HT).
Ça m'a fait découvrir un quotidien basé sur QWERTY et j'avoue que c'est vraiment plus fluide (sauf pour les accents, mais avec la touche compose ça marche finalement pas si mal)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Effectivement il y a bien une distinction (complémentarité) entre la maintenance « technique » (bugs, fonctionnalités) et la maintenance « linguistique » (je ne sais pas si c'est le terme approprié, mais dans tous les cas, je te rejoins sur ces deux aspects
Je verrais bien mettre à la disposition, sur le site de l’application, une collection de dictionnaires et lexiques professionnels qui rendrait ainsi plus visible la fonctionnalité d’éditeur lexical.
Mais ça veut dire aussi qu’il faut un endroit où on peut déposer nos remarques qui devront se classer dans un des types de signalement que je viens d’évoquer et en rappelant en ce qui concerne l’ajout ou la modification de règles qu’on doit donner des précisions (en gros la solution, à charge côté développement de l’intégrer).
Olivier nous avait dit avoir eu une idée qu’il projetait de développer, avant que rien que l’idée de Grammalecte lui donne des boutons. Peut-être pourra-t-il t’en dire un peu plus.
Si je reformule le sujet, l'idée est d'avoir une interface de constitution collaborative de dictionnaires/lexiques, c'est bien ça ?
Il faudra aussi voir comment modifier la page Grammalecte sur le site des extensions de LibreOffice. Au besoin je peux demander à la personne qui s’occupe de la validation des extensions sur le site.
Je pense qu'Olivier va nous donner l'accès (c'est bien lui qui le gère jusqu'à présent ?)
Grammalecte propose une fonctionnalité de modification du champ «Auteur». Il faudrait que ça modifie de façon à ce quand on exporte le fichier en EPUB avec l’extension Writer2xhtml cette modification soit bien conservée, ce qui n’est pas le cas.
Intéressant. Je viens de découvrir la fonctionnalité, j'aurais imaginé qu'elle soit intégrée dans les propriétés du document (ou dit autrement : que sa modification soit proposée dans l'écran d'édition des propriétés du document intégré dans Libreoffice, mais manifestement ça n'y est pas)
Ah, autre chose, je ne sais pas (plus?) comment Grammalecte gère les marques de trucs à corriger. Mais il faudrait sans doute des retours de personnes daltoniennes si c’est Grammalecte qui s’en occupe.
Je crois que dans Libreoffice ça reprend l'interface classique (soulignement rouge et vert ondulé selon que c'est une erreur d'orthographe ou de grammaire)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Si je parvenais un jour à remplacer antidote, ne fut-ce que pour la correction, je serais prêt à payer plusieurs dizaines d’euros par an !
Qu'est-ce qui fait que tu pourras utiliser Grammalecte à la place d'Antidot (ou ne pourra pas) ?S'agit-il de qualité des corrections ? De la qualité du dictionnaire ? de Fonctionnalités bugguées ou manquantes ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Ça coûte combien à la restauration ? Il me semble que sur ce genre d'offre tu as des frais lorsque tu ressors tes données (ce n'est pas une critique, il faut bien que le service soit payé, mais il faut le prendre en compte)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Quand tu parles de reprendre la maintenance (ce qui serait déjà formidable sachant qu'à chaque mise à jour de LibreOffice, je me demande si Grammalecte va continuer à fonctionner), tu ne parles pas de nouveaux développement j'imagine. Ou bien tu penses pouvoir faire évoluer le logiciel ?
C'est la question : un client nous a sollicité pour faire des travaux sur Grammalecte. Ce sont des technologies que l'on connait donc on sait faire techniquement.
Ce que j'envisage, c'est soi "simple maintenance" (correction de bugs, faire en sorte que ça continue de tourner " soit aller plus loin - ajout de fonctionnalités ou autre.
J'envisage une campagne de financement participatif pour relancer le projet et nous permettre de nous y plonger sérieusement (professionnellement parlant) mais ça dépend aussi de ce qui est attendu de ses utilisateurs, de ce qui pourrait être intéressant comme développements, etc.
Je suis intéressé par tout retour sur le sujet.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je suis en train de voir avec Olivier (dev de Grammalecte) pour reprendre la maintenance de Grammalecte avec Algoo et je suis donc intéressé d'un retour de "performance" de language tool.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je m'apprête à parler de galae, mais le retour d'un client est forcément plus pertinent que celui de l'éditeur. Merci 👌
Pour les carnets d'adresses et agendas, une migration se fait généralement sous la forme export/import (ce qui est effectivement manuel).
On essaie effectivement de simplifier la migration/ l'embarquement ; migrer ses emails fait souvent peur mais en réalité c'est qqchose qui se fait très bien, et c'est totalement transparent pour ses interlocuteurs quand on a son propre domaine (aucune coupure de service, aucun email perdu pendant la phase de migration)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Il faut utiliser un logiciel qui va le gérer à ta place (ou le faire à la main).
Ça fait partie des compétences qu'ont les logiciels de gestion de newsletter.
Tu peux l'héberger toi même et le connecter sur le serveur SMTP de ton prestataire.
Tu peux aussi prendre un prestataire qui te fournit un accès SMTP.
Pour les logiciels, j'en connais 2 qui feront l'affaire (qui sont libres) :
mailtrain - mais il est surtout adapté (à mon sens) si tu veux faire des mises en page évoluées
listmonk - interface simple et claire, paramétrage simple des débits.
Les deux proposent les mécanismes d'inscription, désinscription, récupération des données personnelles et suppression définitive - ce dont tu as besoin si tu veux être conforme au RGPD sans faire d'effort.
Avec Galae, on envisage de proposer un service de newsletter avec listmonk.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Mais à part un viewer IFC, je suis pas sûr de voir les spécificités liées au BIM.
Tracim intègre aussi un viewer IFC, mais l'intérêt de Tracim pour le BIM est surtout qu'il s'intègre avec datBIM et toute la "stack" associée pour le BIM. En clair : Tracim apporte une organisation et le versionning des fichiers d'un projet BIM, mais le vrai boulot du BIM reste dans les outils dédiés.
J'ai du mal à voir ce qu'apporte l'intégration BIM dans Open Project
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je ne demande si l'auteur a compris l'enjeu (de la dette technique)
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Most Technical Problems Are Really People Problems. Évalué à 4.
Merci pour ce long commentaire. Je ne vais pas réagir sur tout mais sur 3 points principaux.
Rappel du contexte : je gère une entreprise indépendante qui produit et déploie des logiciels libres. L'aspect « indépendant » de l'entreprise est fondamental dans ma vision car chaque euro dépensé est un euro qui sort de notre trésorerie, chaque euro dépensé pour des travaux non prioritaire est un euro investi avec un retour sur investissement imprévisible.
Je prends un exemple simple : dans le contexte que j'évoque, nous travaillons sur un projet de développement commandé par un client. Dans ce cas, le bien est « simple » : c'est quand ça répond au projet et au cahier des charges signés entre l'entreprise et le client. Ni plus, ni moins :
Ce n'est ni du libéralisme, ni du capitalisme : c'est de la gestion de rentabilité.
C'est le nerf de la guerre d'une entreprise, y compris une SCOP.
Pour s'occuper correctement des besoins des employés, une entreprise doit déjà être correctement rentable.
Pour être plus/mieux rentable il y a deux leviers :
Dans mon parcours de chef d'entreprise (depuis plus de 10 ans maintenant), les plus militants pour « faire les choses à l'état de l'art sans dette » étaient paradoxalement les plus exigeants sur le sujet des besoins individuels des employés.
Les travaux qui ont apporté le plus de valeur à mon sens (valeur = bénéfices vs coût) :
Dans ces exemples, à part pour la partie architecture, il y a de la dette. Et pour la partie architecture, en réalité Tracim avait déjà 5 ans d'existence - donc des lacunes et des évolutions voulues bien identifiées.
La dette permet d'arriver « en avance » sur le marché par rapport aux moyens financiers qu'on a. Ça permet de signer avec des clients qu'on aurait loupé sans cela. Ça rembourse le surcoût lié à l'endettement (car au final les travaux de refonte coûtent)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je ne demande si l'auteur a compris l'enjeu (de la dette technique)
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Most Technical Problems Are Really People Problems. Évalué à 4.
En plus de 10 ans de boîte, je n'ai jamais eu de client qui parte car on avait trop de dette technique. Parce que c'est trop cher, parce que ça répond mal oui, mais pas parce qu'il y a trop de dette technique.
En revanche, des clients qui ne viennent pas parce qu'il manque une fonctionnalité, oui. Et pour réussir à les signer quand même, il n'y a rien de mieux qu'une fonctionnalité « ajoutée à l'arrache » et qui est retravaillée en parallèle de la signature du client ou de la mise en place.
Mais pour être capable de faire ça, il faut des développeurs qui comprennent l'enjeu et sont pro-actif dans cette stratégie de dette.
Ça ne veut pas dire saloper le travail, ça veut dire livrer vite même si un peu moche avec l'idée de rectifier / améliorer ensuite.
Certains vont me dire « oui on sait ce que ça donne ensuite ça passe sous le tapis » . Possible : si ça marche bien il n'y a pas de raison de retravailler la fonctionnalité (ou pas tout de suite).
En revanche, le prospect que tu n'as pas signé, tu as aucune chance de le voir revenir.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je ne demande si l'auteur a compris l'enjeu (de la dette technique)
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Most Technical Problems Are Really People Problems. Évalué à 3.
Mon postulat est que rien n'est mal fait : c'est fait avec les moyens, les objectifs et la compréhension du moment. Et c'est donc de la dette si après coup ça semble inadapté ou mal fait.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je ne demande si l'auteur a compris l'enjeu (de la dette technique)
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Most Technical Problems Are Really People Problems. Évalué à 2.
La dette n'est pas un travail bâclé : la dette c'est emprunter du temps de développement à venir pour livrer plus rapidement une première version (ou des premières versions).
Et c'est précisément pour satisfaire le marché - parfois juste pour être le premier.
Si la langue de ton management c'est des montants en euros, il est naturel de convertir ta vision technique en euros : c'est la meilleure manière de les convaincre.
Si ton management sait qu'il s'est endetté, il sait aussi (normalement) qu'il faut qu'il rembourse pour pouvoir de nouveau emprunter lorsqu'il en aura besoin.
La dette n'est pas du travail mal fait. La dette, c'est du travail court-terme (ou moyen-terme) qui a vocation à être remboursé ; et comme une dette financière, tu rembourses + que ce que tu as emprunté. En revanche, ce surcoût est censé t'avoir permis de gagner plus - donc le calcul au final est positif, même une fois que tu as terminé de rembourser.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Mille merci
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Grammalecte v2.3. Évalué à 5.
Je n'avais pas fait le lien avec Grammalecte ; je reproduis ce problème effectivement (j'ai commenté le ticket)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Je ne demande si l'auteur a compris l'enjeu (de la dette technique)
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Most Technical Problems Are Really People Problems. Évalué à 5. Dernière modification le 17 décembre 2025 à 08:38.
Ça parle longuement de dette technique. Puis vient ceci :
La réalité, dans une boîte, c'est que la dette technique doit être vue et évaluée par sa valeur « business » et uniquement cela. Peu importe que le management ait des compétences techniques.
Les ingénieurs veulent souvent « faire bien » et malheureusement même « faire mieux » . Plus facile à maintenir. Mieux conçu. Plus robuste. Mieux testé. D'ailleurs ça vaut pour les autres métiers : une personne de la comm' voudra « toujours faire un peu plus ». Un peu mieux mis en page. Des goodies un peu plus sympas. Un design un peu plus esthétique. Des vidéos un peu mieux montées.
Mais le besoin (de l'entreprise) n'est pas de faire mieux. Son besoin est de faire bien, juste bien.
Et s'il y a du temps dispo, documenter, industrialiser et normaliser pour que la prochaine fois, ce soit mieux.
Sur le fond du sujet, je suis relativement d'accord : les problèmes techniques sont en fait des problèmes humains qui sont en fait des problèmes de désalignement entreprise/collaborateur.
Est-ce que l'entreprise a tord d'être complaisante ? Est-ce que l'ingénieur a raison de vouloir éviter la dette technique à tout prix ? Ce qui me semble important, c'est surtout d'évoluer (en tant que personne) dans un écosystème (entreprise, marché) dont on partage les valeurs.
Et ça, ça veut dire se renseigner et s'ouvrir aux considérations non techniques.
Sans cet intérêt, sans cette ouverture, c'est perdu d'avance.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: LSP
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Grammalecte v2.3. Évalué à 4.
Je ne connaissais pas LSP. Est-ce un protocole largement utilisé ? Si je regarde le repo github de LanguageTool et plus précisément celui de languagetool-languageserver, visiblement le support de LSP n'a pas bougé depuis 4 ans.
Quelqu'un ici aurait un retour d'expérience / des infos sur le sujet ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Bravo Olivier pour cette nouvelle version !
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Grammalecte v2.3. Évalué à 10.
Comme indiqué dans le journal, nous allons reprendre le projet et pour cela il va y avoir du pain sur la planche.
Comme discuté par ailleurs, il y a les aspects purement techniques — pas d'inquiétude de mon côté de ce point de vue ; mais il y a aussi les aspects « produit » et langue française à reprendre ; et peut-être l'aspect communautaire à réamorcer.
Nous allons communiquer officiellement début janvier sur la reprise du projet — plan d'action, roadmap et probable campagne de financement participatif (pour laquelle nous solliciterons les contributions individuelles mais aussi et surtout institutionnelles).
En tout cas, sacré boulot Olivier pour cette nouvelle version (et pour les précédentes) - je ne m'attendais pas à un contenu aussi riche. Ça n'a pas dû être de tout repo de reprendre le projet après sa phase de sommeil … et merci pour toutes les explications que tu m'as données en privé.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: sailfish? il a eu sa chance..
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Un smartphone sous… Linux ? Découvrez le Jolla Phone, fabriqué en Europe. Évalué à 5.
Sailfish semble avoir une cible d'usages plus variée que 100% mobile.
Les os "installés à la main" sur un mobile acheté par ailleurs, j'ai essayé, ça a marché mais c'est de l'énergie que je préfère mettre ailleurs aujourd'hui.
L'histoire racontée par Jolla me parle plus que Fairphone (dont le marketing a l'air bien "à l'américaine").
Ça m'a l'air d'être la seule alternative pour sortir du duopole Android/ios sans nécessiter des heures de bidouille.
C'est européen.
Jolla donne l'impression d'être une boîte pérenne économiquement (c'est complètement subjectif, c'est basé sur un marketing sobre - ils en font pas des caisses, et ils sont présents dans d'autres activités que le téléphone mobile).
Bref, ça m'a donné envie d'essayer et visiblement il y a le C2 dispo à la vente
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Retour d'expérience sur le Jolla C2
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Un smartphone sous… Linux ? Découvrez le Jolla Phone, fabriqué en Europe. Évalué à 4.
Retour en 2 billets de blog (relativement succincts) d'un client du modèle C2
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Ils arrêtent le produit ? Ils arrêtent l'opensource ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Minio ferme les portes. Évalué à 2.
Si quelqu'un a des infos, je suis preneur …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Nombre de ports limité
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Avis sur un Framework 12. Évalué à 3.
J'ai un peu hésité personnellement pour 2 raisons :
Je suis finalement resté sur mon choix de cœur historique : la gamme Portégé.
Historiquement c'était Toshiba, aujourd'hui c'est Dynabook.
C'est pas vraiment réparable (la RAM est soudée - c'est LE point problématique), c'est pas conçu pour être évolutif, c'est vendu avec Windows, et désormais c'est clavier QWERTY uniquement.
Mais c'est hyper léger (moins de 1kg pour un 13 pouces) , boîtier en magnésium hyper résistant et "pas mou", il y a un max de ports.
Cf. https://asia.dynabook.com/laptop/portege-x30l-m/
C'est pas distribué officiellement en Europe, il faut passer par des moyens détournés pour en acheter.
J'ai pas trouvé d'alternative avec autant de ports sur les petits formats - je suis intéressé si vous en connaissez (je parle de gamme "pro", budget en conséquence entre 1500 et 2000€ HT).
Ça m'a fait découvrir un quotidien basé sur QWERTY et j'avoue que c'est vraiment plus fluide (sauf pour les accents, mais avec la touche compose ça marche finalement pas si mal)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Nombre de ports limité
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Avis sur un Framework 12. Évalué à 2.
Fragile dans quel sens ? mécaniquement ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La correction grammaticale fonctionne bien ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal J'ai failli le faire. Évalué à 3.
Merci pour ce long message !
Effectivement il y a bien une distinction (complémentarité) entre la maintenance « technique » (bugs, fonctionnalités) et la maintenance « linguistique » (je ne sais pas si c'est le terme approprié, mais dans tous les cas, je te rejoins sur ces deux aspects
Si je reformule le sujet, l'idée est d'avoir une interface de constitution collaborative de dictionnaires/lexiques, c'est bien ça ?
Je pense qu'Olivier va nous donner l'accès (c'est bien lui qui le gère jusqu'à présent ?)
Intéressant. Je viens de découvrir la fonctionnalité, j'aurais imaginé qu'elle soit intégrée dans les propriétés du document (ou dit autrement : que sa modification soit proposée dans l'écran d'édition des propriétés du document intégré dans Libreoffice, mais manifestement ça n'y est pas)
Je crois que dans Libreoffice ça reprend l'interface classique (soulignement rouge et vert ondulé selon que c'est une erreur d'orthographe ou de grammaire)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La correction grammaticale fonctionne bien ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal J'ai failli le faire. Évalué à 4.
Merci pour ce retour !
Qu'est-ce qui fait que tu pourras utiliser Grammalecte à la place d'Antidot (ou ne pourra pas) ?S'agit-il de qualité des corrections ? De la qualité du dictionnaire ? de Fonctionnalités bugguées ou manquantes ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Tracm - Simple à utiliser (pas d'intégration Git)
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Choix d’un outil pour gérer des projets sur Linux. Évalué à 6.
Disclaimer: je suis le créateur de Tracim
C'est une appli web à déployer (avec Docker si tu ne veux pas t'embêter)
Tu peux tester en créant un compte personnel gratuit sur Tracim HOME.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: SSD uniquement pour du volatile
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Les SSD non alimentés dans votre tiroir perdent lentement leurs données. Évalué à 5.
J'ai pas dit que c'était cher : je disais juste que le coût ce n'est pas que le stockage par moi.
Je suis d'accord que payer 100€ - même 1000€ en cas d'incendie c'est ok (pour une boîte en tout cas)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: SSD uniquement pour du volatile
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Les SSD non alimentés dans votre tiroir perdent lentement leurs données. Évalué à 6.
Ça coûte combien à la restauration ? Il me semble que sur ce genre d'offre tu as des frais lorsque tu ressors tes données (ce n'est pas une critique, il faut bien que le service soit payé, mais il faut le prendre en compte)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La correction grammaticale fonctionne bien ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal J'ai failli le faire. Évalué à 10.
C'est la question : un client nous a sollicité pour faire des travaux sur Grammalecte. Ce sont des technologies que l'on connait donc on sait faire techniquement.
Ce que j'envisage, c'est soi "simple maintenance" (correction de bugs, faire en sorte que ça continue de tourner " soit aller plus loin - ajout de fonctionnalités ou autre.
J'envisage une campagne de financement participatif pour relancer le projet et nous permettre de nous y plonger sérieusement (professionnellement parlant) mais ça dépend aussi de ce qui est attendu de ses utilisateurs, de ce qui pourrait être intéressant comme développements, etc.
Je suis intéressé par tout retour sur le sujet.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# La correction grammaticale fonctionne bien ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal J'ai failli le faire. Évalué à 10.
Je suis en train de voir avec Olivier (dev de Grammalecte) pour reprendre la maintenance de Grammalecte avec Algoo et je suis donc intéressé d'un retour de "performance" de language tool.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: rext migration grandi -> galae.net
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Migration de Scaleway vers Infomaniak. Évalué à 2.
Je m'apprête à parler de galae, mais le retour d'un client est forcément plus pertinent que celui de l'éditeur. Merci 👌
Pour les carnets d'adresses et agendas, une migration se fait généralement sous la forme export/import (ce qui est effectivement manuel).
On essaie effectivement de simplifier la migration/ l'embarquement ; migrer ses emails fait souvent peur mais en réalité c'est qqchose qui se fait très bien, et c'est totalement transparent pour ses interlocuteurs quand on a son propre domaine (aucune coupure de service, aucun email perdu pendant la phase de migration)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: oublie
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Solution pour diffuser une newsletter/des emails. Évalué à 5.
Bah ça dépend :
Bref, proposer une solution alternative sans connaître les tenants et aboutissants, c'est un peu "mettre la charrue avant les boeufs".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Si ton serveur SMTP limite le débit d'envoi ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Solution pour diffuser une newsletter/des emails. Évalué à 10.
Il faut utiliser un logiciel qui va le gérer à ta place (ou le faire à la main).
Ça fait partie des compétences qu'ont les logiciels de gestion de newsletter.
Tu peux l'héberger toi même et le connecter sur le serveur SMTP de ton prestataire.
Tu peux aussi prendre un prestataire qui te fournit un accès SMTP.
Pour les logiciels, j'en connais 2 qui feront l'affaire (qui sont libres) :
Les deux proposent les mécanismes d'inscription, désinscription, récupération des données personnelles et suppression définitive - ce dont tu as besoin si tu veux être conforme au RGPD sans faire d'effort.
Avec Galae, on envisage de proposer un service de newsletter avec listmonk.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Sensationalisme ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Chute du Bitcoin : plus d’un milliard de dollars s’est évaporé du marché crypto en l’espace de 24 h. Évalué à 10.
Personne n'a rien perdu à part l'espoir de gagner (encore plus) de l'argent …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Intéressant..
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Open Project et BIM !. Évalué à 2.
Mais à part un viewer IFC, je suis pas sûr de voir les spécificités liées au BIM.
Tracim intègre aussi un viewer IFC, mais l'intérêt de Tracim pour le BIM est surtout qu'il s'intègre avec datBIM et toute la "stack" associée pour le BIM. En clair : Tracim apporte une organisation et le versionning des fichiers d'un projet BIM, mais le vrai boulot du BIM reste dans les outils dédiés.
J'ai du mal à voir ce qu'apporte l'intégration BIM dans Open Project
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo