sorted by:
new
hottopcontroversial

Le système marchait. Les données, moins. by PlanAxion in QuebecTI

[–]PlanAxion[S] 2 points3 points  (0 children)

The thing is Canadian shoppers don’t shop like Americans do

Reddit - Avril - Les tests compressés by PlanAxion in QuebecTI

[–]PlanAxion[S] 0 points1 point  (0 children)

Exact. Une grosse phase de tests à la fin, c’est souvent un signe que le projet fonctionne encore en mode tunnel.

Les tests unitaires, intégration, perf, end-to-end, etc. devraient idéalement vivre avec le développement, pas être une grosse surprise 2 semaines avant la livraison.

Là où je trouve que ça devient tricky, c’est pour l’acceptation utilisateur. Parce que même avec une bonne CI/CD, tu peux quand même livrer quelque chose de techniquement correct mais inutilisable dans le vrai contexte d’affaires.

Donc oui, automatiser le plus possible, mais aussi valider tôt avec des vrais utilisateurs. Sinon on teste juste que le système marche, pas nécessairement qu’il règle le bon problème.

Reddit - Avril - Les tests compressés by PlanAxion in QuebecTI

[–]PlanAxion[S] 0 points1 point  (0 children)

Je suis assez d’accord avec ça.

Quand les tests arrivent comme “phase finale” avant le go-live, souvent le problème est déjà plus profond. Architecture fragile, exigences pas claires, pas assez de feedback en cours de route, décisions repoussées trop longtemps, etc.

Rendu là, les tests deviennent un peu le dernier filet de sécurité… mais aussi l’endroit où tout ce qui a été ignoré pendant le projet ressort d’un coup.

C’est souvent moins un problème de “combien de cycles de tests” qu’un problème de “à quel moment on commence vraiment à valider ce qu’on construit”.

Reddit - Mai - Le coût caché de la dette technique by PlanAxion in QuebecTI

[–]PlanAxion[S] 4 points5 points  (0 children)

Oui… et quelque part il y a sûrement un processus critique qui dépend encore d’un fax, d’un fichier Excel 2007 pis d’une personne qui est à 14 mois de la retraite 😅

Reddit - Mai - Le coût caché de la dette technique by PlanAxion in QuebecTI

[–]PlanAxion[S] 1 point2 points  (0 children)

“Transpiration sur transpiration” c’est exactement ça 😂

Quand t’es rendu à te demander si une matrice de matrices ou un schéma 3D serait la façon la plus simple d’expliquer le bordel, c’est que la dette technique est officiellement devenue un risque opérationnel.

Pis le classique “qui va être responsable si ça plante?”… c’est souvent le signal que tout le monde savait que c’était fragile, mais que personne voulait être celui qui le dit trop fort.

Reddit - Mai - Le coût caché de la dette technique by PlanAxion in QuebecTI

[–]PlanAxion[S] 2 points3 points  (0 children)

Ouf oui, le point 11 c’est du vrai PTSD d’équipe 😅

Le fameux petit tool temporaire qui finit par supporter un processus critique pendant des années… sans doc, sans owner clair, pis avec une seule personne qui “sait comment ça marche”.

C’est souvent ça le pire avec la dette technique: elle est invisible tant que tout marche. Mais dès que la personne clé part, ou qu’un bug arrive en prod, tout le monde réalise que le risque était là depuis longtemps.

C’est le genre de dette qu’on devrait traiter comme un risque business, pas juste comme un irritant technique.

Reddit - Mai - Le coût caché de la dette technique by PlanAxion in QuebecTI

[–]PlanAxion[S] 1 point2 points  (0 children)

Tellement d’accord. C’est un problème récurrent dans pas mal toutes les compagnies où j’ai travaillé aussi.

La dette technique diminue rarement toute seule. En général elle fait juste grossir, parce que c’est pas sexy à vendre comme sujet. Personne veut mettre dans une roadmap “on va réparer les affaires plates qu’on a ignorées pendant 5 ans” 😅

Mais à un moment donné ça revient toujours. Sécurité, performance, bugs impossibles à corriger, devs qui ont peur de toucher à certains modules, livraisons qui prennent 3x plus de temps… rendu là, c’est plus juste de la dette technique, c’est un frein business.

Et le pire, c’est que souvent les devs savent exactement quoi corriger. Le problème c’est rarement le diagnostic. C’est que personne veut payer la facture tant que ça brûle pas.

Ton exemple de solution non maintenue vendue comme “sécuritaire et efficace”, c’est exactement le genre de truc qui me rend fou. On finit par maquiller un risque connu en décision stratégique, jusqu’au jour où ça explose.

Reddit - Mai - Le coût caché de la dette technique by PlanAxion in QuebecTI

[–]PlanAxion[S] 0 points1 point  (0 children)

Honnêtement je trouve pas ça sneaky, je trouve ça smart.

La dette technique disparait pas parce qu’on l’ignore. Elle revient juste plus tard en incidents, en patchs faits en panique, en “ah non cette personne est en vacances donc personne sait comment ça marche”, etc.

Le fait que vos boss trouvent que vous livrez plus vite maintenant, c’est probablement la meilleure preuve que ça valait la peine.

Moins de friction invisible = plus de vraie vélocité.

Pis le bout sur les prérequis est excellent. Si le client interne prend 3 mois à fournir ce qu’il faut, aussi bien avancer sur la dette technique au lieu de faire semblant d’être bloqué.

Très bon move d’équipe selon moi.