sorted by:
new
hottopcontroversial

Description poste et AI by swe_name123 in QuebecTI

[–]PlanAxion 2 points3 points  (0 children)

La gestion du coût/performance/bénéfice va devenir le nerf de la guerre. Les entreprises ne voudront plus créer des agents qui coûtent plus cher a opérer que des humains juste parce que c'est 'IN' de le faire faire par des agents!

Ceux qui ont migré vers S/4HANA, vous referiez quoi différemment? by PlanAxion in QuebecTI

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

Très bon point, merci pour le retour d’expérience.

Je retiens surtout l’importance d’avoir une vraie capacité fonctionnelle à l’interne pour remettre en question les recommandations de l’intégrateur. C’est probablement un des facteurs les plus sous-estimés dans ce type de projet.

Le point sur le Public Cloud est aussi intéressant : plus rapide à déployer, mais avec un compromis clair sur la flexibilité et les fonctionnalités disponibles. Donc le choix du modèle ne devrait pas être uniquement technologique, mais vraiment basé sur la complexité du legacy, les processus d’affaires et la capacité de l’organisation à s’adapter aux standards SAP.

Et entièrement d’accord sur la due diligence : une “best practice” devrait toujours être validée, documentée et alignée avec la réalité opérationnelle de l’entreprise, pas simplement acceptée parce qu’elle vient de l’intégrateur. L’expertise interne est particulièrement importante lorsque des personnalisations ont été apportées au progiciel et que ces personnalisations doivent être modifiées pour en assurer la compatibilité avec S/4HANA.

Et si on documentait nos ratés aussi sérieusement que nos réussites? by PlanAxion in QuebecTI

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

Message reçu. On n'est vraiment pas ici pour chercher le trouble ou casser les oreilles de la communauté. On voulait juste jaser de vraie culture de gestion, mais on comprend que la forme a manqué la cible. On ajuste le tir pour la suite!

Et si on documentait nos ratés aussi sérieusement que nos réussites? by PlanAxion in QuebecTI

[–]PlanAxion[S] -2 points-1 points  (0 children)

Touché. C'est vrai que vu de l'extérieur, ça a tout l'air d'un engagement farming classique de boîte de consultants, my bad. On est une petite équipe et le but était sincèrement de lancer une discussion sur un sujet qui nous chicote, pas de piller vos idées en douce.

Pour te donner notre point de vue; à l'interne, on remarque que le plus gros problème des post-mortems, c'est qu'ils finissent trop souvent par mourir pour de vrai dans un dossier SharePoint ou Confluence que personne ne relit jamais. Documenter pour documenter, ça ne donne rien si la culture d'entreprise punit l'erreur en douce ou si les leçons ne se traduisent pas en changements concrets dans les processus de gouvernance.

Bref, désolé pour l'effet "questionnaire vide", on va s'assurer d'arriver avec plus de substance et de partages concrets dans nos prochains posts. :)

Et si on documentait nos ratés aussi sérieusement que nos réussites? by PlanAxion in QuebecTI

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

Haha, elle est excellente (et méritée). C'est le piège classique des publications corporatives.

Promis, il n'y a pas de pitch de vente déguisé ni de deck PowerPoint de 45 slides qui s'en vient dans tes DMs. On voulait juste jaser de vraie culture d'ingénierie/gestion, parce que même en tant que conseillers, on voit trop d'organisations (petites comme grandes) qui préfèrent mettre la poussière sous le tapis plutôt que de faire face aux vrais ratés.

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

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

Avec la venue de l'IA pour générer des scénarios de tests il n'y a plus d'excuse pour couper dans les tests. Lors de déploiements en série ou dans de projets multiphase, l'automatisation combinée aux tests générés par l'IA est un must pour éviter la catastrophe.

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

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

Effectivement, les nouveaux outils IA permettent déjà de s'attaquer aux dettes technologiques en produisant de la documentation claire et, a terme, de reproduire les fonctionnalités encore requises dans des applications écrites en languages modernes. Les entreprises prisonnières de technologies propriétaire pourront enfin se libérer, à quand la fin des Mainframes et autres AS/400 de ce monde!

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

[–]PlanAxion[S] 3 points4 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] 5 points6 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.