Projets numériques : 4 facteurs d'échec | Les Echos

Un tiers des entreprises à travers le monde ont déjà abandonné un projet numérique au cours des deux dernières années. C’est ce que révèle la vaste enquête « The Digital Transformation PACT », menée par Fujitsu dans treize pays du globe, dont la France et l’Italie, auprès de 1.625 dirigeants de moyennes et grandes entreprises des secteurs public et privé. Tous les personnes interrogées avaient réalisé un projet de transformation numérique ou avaient exprimé leur volonté de le faire prochainement. Au final, leurs échecs en la matière leur auront coûté en moyenne 423.000 euros. Pour plus d’un quart de l’échantillon, ce prix s’est même élevé à 555.000 euros ! Pis, deux dirigeants sur trois (66 %) expliquent que le coût des revers subis retarde le processus de transformation de leur société.

« Les entreprises parviennent difficilement à réunir les quatre éléments stratégiques nécessaires à la transformation digitale : les personnes, les actions, la collaboration et la technologie », analysent les auteurs de l’étude.  « Mettre en oeuvre la transformation digitale ne se résume pas aux seules avancées technologiques ». Les experts dégagent quatre facteurs d’échec fréquents, et insistent sur la nécessaire co-existence des bonnes compétences, mais aussi sur la qualité des partenariats.

#1 Un manque de compétences

La grande majorité (90 %) des dirigeants d’entreprise estiment prendre des mesures pour développer l’expertise numérique de leurs employés. Cependant, 70% d’entre eux admettent que leur organisation souffre d’un manque de compétences  en la matière. Et 80 % déclarent même que cette carence constitue le plus grand obstacle pour lutter contre la cyber-criminalité. Il n’est donc pas surprenant que la quasi-totalité des dirigeants (93%) juge que le perfectionnement des compétences « digitales » sera déterminant pour le succès de leur entreprise d’ici à trois ans. Ils sont toutefois un peu moins nombreux (83 %) à penser que l’intelligence artificielle transformera les compétences requises, d’ici à 2020.

#2 Des projets déconnectés de la stratégie commerciale

Neuf dirigeants sur dix affirment que leur organisation dispose d’une stratégie numérique clairement définie. Si 83 % d’entre eux se disent confiants au sujet de sa bonne compréhension par tous les échelons de l’entreprise, près des trois quarts indiquent que les projets numériques entrepris ne sont pas toujours en phase avec la stratégie commerciale globale. Par ailleurs, 72 % affirment que la réalisation de projets « fantômes » constitue le seul moyen d’obtenir qu’une partie de leur organisation puisse produire de l’innovation de manière significative.

#3 Des partenariats fragiles

Dans 63% des organisations, des projets de cocréation ont entrepris avec des partenaires, qu’ils soient experts en technologies (64%), clients (42%) ou start-up (37%). A 79 %, les dirigeants sondés seraient prêts à partager des informations sensibles dans le cadre de ces partenariats mais les trois-quarts indiquent aussi qu’en l’absence de succès à court terme, ils mettraient rapidement un terme à ces partenariats.

#4 Une appréhension face aux nouveaux enjeux

Plus de la moitié des dirigeants interrogés prévoient de recourir à des solutions de cyber-sécurité (52 %) ou d’internet des objets (IoT, 51 %) dans les douze prochains mois. Ils sont un peu moins nombreux à songer à utiliser le « cloud computing » (47 %) ou l’intelligence artificielle (46 %). Enfin, ils sont 86 % à dire que leur capacité d’adaptation sera cruciale pour la survie de l’entreprise au cours des cinq prochaines années.

Source : Projets numériques : 4 facteurs d’échec

Documenter vos projets autrement avec git et asciidoc

Un collègue m’a fourni une vidéo intéressante sur une manidère différente de gérer une documentation projet : https://youtu.be/1rKgVF5CEEY
Il est vrai que cela fait un moment qu’on tourne autour du pot. Les wikis c’est bien mais le bon logiciel est toujours délicat à trouver. Sans détailler la réflexion ici (peut être une autre fois) il y a toujours une contrainte qui fait que ce n’est jamais parfait…
Je suis donc en train de me pencher sur une mouvance qui me semble intéressante : gérer sa documention as a code. En simplifiant cela veut dire que votre documentation est gérée dans un dépot git, avec un outil de collaboration sympa comme gitlab et  des fichiers sous forme plain text avec une syntaxe simple et lisible comme markdown ou asciidoc (j’ai tendance à préférer le second actuellement).
Cela vous permet d’avoir une documentation où chacun peut collaborer simplement (coucou pull request). De plus, il se trouve que github et gitlab intègrent les syntaxes asciidoc et markdown en natif, vous pouvez donc déjà naviguer dans votre documentation directement sur leur site web.
Le fin du fin sera de générer un site statique joli (avec un moteur de recherche) et si possible une version pdf. C’est là que l’excellent gitbook entre en action.
Enfin, pour mettre la cerise sur le gateau, vous pouvez rebuilder votre site documentaire de manière automatisée avec un job gitlab ci bien senti.
Au passage, pour le job gitlab je me suis construit une image docker gitbook qui m’aide bien.
Cette manière de faire semble s’étendre car même chez owasp on a choisi de construire le nouveau developer guide de cette manière sur github.
Que du bon donc pour l’instant ! A creuser à l’usage.

Tom Wujec: Build a tower, build a team | Video on TED.com

Tom Wujec: Build a tower, build a team | Video on TED.com.
Une expérience intéressante sur la manière de travailler en équipe sur un projet. Elle permet de montrer facilement les travers qu’on peut avoir dans notre manière de faire et évidement comment s’y prendre mieux. Le truc le plus marrant c’est que les enfants de maternelle, s’en sortent naturellement mieux (en moyenne) sur ce genre d’expérience…

Estimer un temps de développement, c’est difficile – HTeuMeuLeu

Estimer un temps de développement, c’est difficile – HTeuMeuLeu.
Tout à fait vrai ! Je partage assez cette vision. C’est d’ailleurs pour cela que vendre et gérer un projet est si difficile dans l’informatique.
Le seul moyen de devenir réellement cohérent est d’avoir déjà fait la route (ou quelque chose d’approchant) au moins une fois. Ce n’est pas toujours possible quand on innove, du moins pour référence les compétences que l’on avait jusqu’ici.
C’est sans doute ce que les différentes méthode projet essayent de gérer tant bien que mal mais il n’y aura jamais de réelle solution à ce mal (sauf avoir déjà fait).
C’est dommage puisque dans l’absolu le client n’attend qu’une chose (hormis le traditionnel pas cher) c’est d’avoir une vision précise de combien il va devoir débourser du début à la fin.