En relisant la liste des fonctionnalités, il y a d'autres choses qui me perturbent :
Always display user language as en-US to websites, in order to protect the language used in the browser and in the OS.
Disable search and form history.
Disable form autofill.
Disable disk cache and clear temporary files on close.
Enable HTTPS-only mode.
Je suis sûrement pas assez pointu sur la protection de la vie privée mais je ne comprends pas ces fonctionnalités - qui me semblent plutôt aller à l'encontre de l'ergonomie.
Pour le dernier point - HTTPS-only, je trouve ça contre-productif dans mon contexte professionnel :
avant de mettre au point des choses en HTTPS, on le fait en HTTP,
parfois on a des outils « vite fait » qui tournent localement en HTTP
Mettre du HTTPS dans ce contexte c'est juste se compliquer le quotidien.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je n'ai pas testé. J'ai regardé la liste des fonctionnalités de LibreWolf et me suis arrêté au tout premier point : « Delete cookies and website data on close. »
Pas besoin d'aller plus loin pour voir que ça ne répond pas à mon usage : j'ai des outils qui enregistrent notamment des brouillons de commentaires / notes dans le LocalStorage du navigateur. De mon point de vue (de mon usage), c'est une anti-feature de tout purger quand tu fermes l'application.
C'est un comme si « on jetait tous les papiers de mon bureau quand je rentres chez moi le soir »
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Ça fait quelques temps que je me pose sérieusement la question de tester une alternative à Firefox. LibreWolf est trop strict à mon goût (je veux garder une expérience confortable) ; vous avez un retour sur ces alternatives ?
Duckduckgo m'attire (j'utilise déjà le moteur de recherche comme point d'entrée sur le web).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Pourtant de mon point de vue, pour un coût supplémentaire relativement peu élevé, on pourrait isoler beaucoup plus et éviter de refaire le travail dans 20 ans.
Dans le monde économique tel qu'il fonctionne aujourd'hui, la démarche qui me paraît pertinente est d'informer le client et de lui proposer ce surcoût en lui expliquant les bénéfices.
Sur ce sujet particulier, j'ai tendance à me dire que la réglementation devrait imposer des choses
Je me demande si la perception différente que tu peux avoir avec d'autres sur ce fil ne vient pas aussi d'un expérience différente.
Complètement.
J'étais "comme tout le monde" avant de gérer Algoo.
Le commerce c'est facile. Le marketing c'est de l'arnaque. La dette c'est de la merde. Les managers sont des nases. C'est quand même pas sorcier.
Ce genre d'analyse que des gens intelligents qui prennent le temps de réfléchir font régulièrement - mais sans avoir les bases pour faire une analyse pertinente.
Il y a des choses que j'aurais pu comprendre si on me les avait expliqué quand j'étais salarié, mais ça n'est pas arrivé. J'ai donc appris sur le tard, à mon grand regret en tant que dirigeant mais aussi en tant que salarié sur mon parcours passé.
En partageant ici un point de vue bien différent de ce qu'on croise dans les milieux de techniciens, je me dis que j'en aiderai peut-être quelques uns à ajuster leur vision pour qu'elle soit un peu moins machiavélique.
Par exemple, un point important de la réalité économique, c'est que la plupart du temps, un entreprise signe dès contrats avec engagement de résultat. Souvent en s'appuyant sur des estimations fournies par les employés. Qui eux sont rémunérés en engageant de moyen. Déjà rien que pour ça il faut prévoir des marges - mais tu es régulièrement jugé avec ces marges car "tu te fais de l'argent sur le dos du salarié et du client. C'est pas correct".
L'entreprise monétise le risque. Ça choque régulièrement des gens - ce n'est pas pour autant que chacun est prêt à être payé en variable.
Bref.
Je ne me fais pas d'illusion : je sais que ma vision n'est massivement pas partagée ici - mais je ne suis pas en croisade : je partage des billes avec celles et ceux qui pensent qu'un peu de contradictoire les fait progresser.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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
[^] # Re: Découverte
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Votre navigateur vous espionne, mais à quel point ? Vous allez être choqué. Évalué à 2 (+0/-0). Dernière modification le 25 décembre 2025 à 12:21.
Si on fait ça aussi en numérique ça devient vraiment cynique, non ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Découverte
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Votre navigateur vous espionne, mais à quel point ? Vous allez être choqué. Évalué à 4 (+2/-0).
En relisant la liste des fonctionnalités, il y a d'autres choses qui me perturbent :
Je suis sûrement pas assez pointu sur la protection de la vie privée mais je ne comprends pas ces fonctionnalités - qui me semblent plutôt aller à l'encontre de l'ergonomie.
Pour le dernier point - HTTPS-only, je trouve ça contre-productif dans mon contexte professionnel :
Mettre du HTTPS dans ce contexte c'est juste se compliquer le quotidien.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Découverte
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Votre navigateur vous espionne, mais à quel point ? Vous allez être choqué. Évalué à 6 (+4/-0).
Je n'ai pas testé. J'ai regardé la liste des fonctionnalités de LibreWolf et me suis arrêté au tout premier point : « Delete cookies and website data on close. »
Pas besoin d'aller plus loin pour voir que ça ne répond pas à mon usage : j'ai des outils qui enregistrent notamment des brouillons de commentaires / notes dans le LocalStorage du navigateur. De mon point de vue (de mon usage), c'est une anti-feature de tout purger quand tu fermes l'application.
C'est un comme si « on jetait tous les papiers de mon bureau quand je rentres chez moi le soir »
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Découverte
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Votre navigateur vous espionne, mais à quel point ? Vous allez être choqué. Évalué à 3 (+1/-0). Dernière modification le 24 décembre 2025 à 08:11.
Bon, l'article ne parle ni de LibreWolf ni de WaterFox, mais du coup j'ai découvert
Ça fait quelques temps que je me pose sérieusement la question de tester une alternative à Firefox. LibreWolf est trop strict à mon goût (je veux garder une expérience confortable) ; vous avez un retour sur ces alternatives ?
Duckduckgo m'attire (j'utilise déjà le moteur de recherche comme point d'entrée sur le web).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pensée pour Aaron Swartz
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Comment un cofondateur de Mistral AI a piraté des millions de livres quand il travaillait chez Meta. Évalué à 5 (+3/-0).
Si j'ai bien compris ils ont (il a) massivement pompé des sources à partir d'un site pirate ?
C'est du recel du coup ?
Ça ne changera rien probablement aux réelles inquiétudes auxquelles il faudrait qu'il fasse face, mais je trouve ça encore plus fourbe.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Firefox
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Grammalecte v2.3. Évalué à 3 (+1/-0).
Ça y est, le plugin a été accepté sur Firefox 💪
#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é à 7 (+6/-1).
Dans le monde économique tel qu'il fonctionne aujourd'hui, la démarche qui me paraît pertinente est d'informer le client et de lui proposer ce surcoût en lui expliquant les bénéfices.
Sur ce sujet particulier, j'ai tendance à me dire que la réglementation devrait imposer des choses
Complètement.
J'étais "comme tout le monde" avant de gérer Algoo.
Le commerce c'est facile. Le marketing c'est de l'arnaque. La dette c'est de la merde. Les managers sont des nases. C'est quand même pas sorcier.
Ce genre d'analyse que des gens intelligents qui prennent le temps de réfléchir font régulièrement - mais sans avoir les bases pour faire une analyse pertinente.
Il y a des choses que j'aurais pu comprendre si on me les avait expliqué quand j'étais salarié, mais ça n'est pas arrivé. J'ai donc appris sur le tard, à mon grand regret en tant que dirigeant mais aussi en tant que salarié sur mon parcours passé.
En partageant ici un point de vue bien différent de ce qu'on croise dans les milieux de techniciens, je me dis que j'en aiderai peut-être quelques uns à ajuster leur vision pour qu'elle soit un peu moins machiavélique.
Par exemple, un point important de la réalité économique, c'est que la plupart du temps, un entreprise signe dès contrats avec engagement de résultat. Souvent en s'appuyant sur des estimations fournies par les employés. Qui eux sont rémunérés en engageant de moyen. Déjà rien que pour ça il faut prévoir des marges - mais tu es régulièrement jugé avec ces marges car "tu te fais de l'argent sur le dos du salarié et du client. C'est pas correct".
L'entreprise monétise le risque. Ça choque régulièrement des gens - ce n'est pas pour autant que chacun est prêt à être payé en variable.
Bref.
Je ne me fais pas d'illusion : je sais que ma vision n'est massivement pas partagée ici - mais je ne suis pas en croisade : je partage des billes avec celles et ceux qui pensent qu'un peu de contradictoire les fait progresser.
#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 (+1/-1).
C'est le problème de l'entreprise. Si les gens n'étaient pas motivés, c'est une forme de dette.
C'est plus proche du bouddhisme dans l'esprit je pense.
#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 (+3/-1).
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 (+3/-1).
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 (+2/-1).
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 (+2/-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 (+3/-0).
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 (+5/-2). 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é à 3 (+2/-1).
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 (+25/-1).
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é à 6 (+4/-0).
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é à 5 (+3/-0).
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 (+0/-0).
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 (+1/-0).
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 (+0/-0).
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é à 2 (+0/-0).
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 (+2/-0).
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 (+4/-0).
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 (+3/-0).
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